July 2023 - Linux-stable-mirror

[PATCH v2] s390/zcrypt: fix reply buffer calculations for CCA replies

by Harald Freudenberger

The length information for available buffer space for CCA replies is covered with two fields in the T6 header prepended on each CCA reply: fromcardlen1 and fromcardlen2. The sum of these both values must not exceed the AP bus limit for this card (24KB for CEX8, 12KB CEX7 and older) minus the always present headers. The current code adjusted the fromcardlen2 value in case of exceeding the AP bus limit when there was a non-zero value given from userspace. Some tests now showed that this was the wrong assumption. Instead the userspace value given for this field should always be trusted and if the sum of the wo fields exceeds the AP bus limit for this card the first field fromcardlen1 should be adjusted instead. So now the calculation is done with this new insight in mind. Also some additional checks for overflow have been introduced and some comments to provide some documentation for future maintainers of this complicated calculation code. Furthermore the 128 bytes of fix overhead which is used in the current code is not correct. Investications showed that for a reply always the same two header structs are prepended before a possible payload. So this is also fixed with this patch. Signed-off-by: Harald Freudenberger <freude(a)linux.ibm.com> Cc: stable(a)vger.kernel.org --- drivers/s390/crypto/zcrypt_msgtype6.c | 45 ++++++++++++++++++++------- 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c index 247f0ad38362..5ac110669327 100644 --- a/drivers/s390/crypto/zcrypt_msgtype6.c +++ b/drivers/s390/crypto/zcrypt_msgtype6.c @@ -551,6 +551,12 @@ static int xcrb_msg_to_type6_ep11cprb_msgx(bool userspace, struct ap_message *ap * * Returns 0 on success or -EINVAL, -EFAULT, -EAGAIN in case of an error. */ +struct type86_reply_hdrs { + struct type86_hdr hdr; + struct type86_fmt2_ext fmt2; + /* ... payload may follow ... */ +} __packed; + struct type86x_reply { struct type86_hdr hdr; struct type86_fmt2_ext fmt2; @@ -1101,23 +1107,38 @@ static long zcrypt_msgtype6_send_cprb(bool userspace, struct zcrypt_queue *zq, struct ica_xcRB *xcrb, struct ap_message *ap_msg) { - int rc; + unsigned int reply_bufsize_minus_headers = + zq->reply.bufsize - sizeof(struct type86_reply_hdrs); struct response_type *rtype = ap_msg->private; struct { struct type6_hdr hdr; struct CPRBX cprbx; /* ... more data blocks ... */ } __packed * msg = ap_msg->msg; - - /* - * Set the queue's reply buffer length minus 128 byte padding - * as reply limit for the card firmware. - */ - msg->hdr.fromcardlen1 = min_t(unsigned int, msg->hdr.fromcardlen1, - zq->reply.bufsize - 128); - if (msg->hdr.fromcardlen2) - msg->hdr.fromcardlen2 = - zq->reply.bufsize - msg->hdr.fromcardlen1 - 128; + int rc, delta; + + /* limit each of the two from fields to AP bus limit - headers */ + msg->hdr.fromcardlen1 = min_t(unsigned int, + msg->hdr.fromcardlen1, + reply_bufsize_minus_headers); + msg->hdr.fromcardlen2 = min_t(unsigned int, + msg->hdr.fromcardlen2, + reply_bufsize_minus_headers); + + /* calculate delta if the sum of both exceeds AP bus limit - headers */ + delta = msg->hdr.fromcardlen1 + msg->hdr.fromcardlen2 + - reply_bufsize_minus_headers; + if (delta > 0) { + /* + * Sum exceeds AP bus limit - headers, prune fromcardlen1 + * (always trust fromcardlen2) + */ + if (delta > msg->hdr.fromcardlen1) { + rc = -EINVAL; + goto out; + } + msg->hdr.fromcardlen1 -= delta; + } init_completion(&rtype->work); rc = ap_queue_message(zq->queue, ap_msg); @@ -1240,7 +1261,7 @@ static long zcrypt_msgtype6_send_ep11_cprb(bool userspace, struct zcrypt_queue * * as reply limit for the card firmware. */ msg->hdr.fromcardlen1 = zq->reply.bufsize - - sizeof(struct type86_hdr) - sizeof(struct type86_fmt2_ext); + sizeof(struct type86_reply_hdrs); init_completion(&rtype->work); rc = ap_queue_message(zq->queue, ap_msg); -- 2.34.1

1 year, 9 months

2
2
0 0

Backporting commits for generating rpi dtb symbols to stable

by Pali Rohár

Hello, I see that raspberry pi bootloader throws ton of warnings when supplied DTB file does not contain /__symbols__/ node. On RPI 1B rev1 it looks like this: dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found dterror: no symbols found Bootloader also propagates these warnings to kernel via dtb property chosen/user-warnings and they can be read by simple command: $ cat /sys/firmware/devicetree/base/chosen/user-warnings ... Upstream Linux kernel build process by default does not generate /__symbols__/ node for DTB files, but DTB files provided by raspberrypi foundation have them for a longer time. I wanted to look at this issue, but I figured out that it is already solved by just recent Aurelien's patches: e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices") 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices") My testing showed that /__symbols__/ node is required by rpi bootloader for overlay support even when overlayed DTB file does not use any DTB symbol (and reference everything via full node path). So seems that /__symbols__/ node is crucial for rpi bootloader even when symbols from them are not used at all. So I would like to ask, would you consider backporting these two raspberry pi specific patches to stable kernel trees? Upstream kernel would get rid of those bootloader warnings and also allow users to use overlayed dtbs... (Btw, do you know if raspberry pi foundation or broadcom provides source code of that bootloader? It would be interesting to understand it or maybe also fix it...)

1 year, 9 months

4
7
0 0

Re: [stable:linux-4.14.y 4549/9999] drivers/android/binder.c:3355: Error: unrecognized keyword/register name `l.lwz ?ap,4(r20)'

by Jann Horn

On Sun, Jul 16, 2023 at 10:20 PM kernel test robot <lkp(a)intel.com> wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y > head: 60a6e3043cc8b918c989707a5eba5fd6830a08a4 > commit: f40f289b96bf856e1613f17bf9426140e8b89393 [4549/9999] binder: Prevent context manager from incrementing ref 0 > config: openrisc-randconfig-r002-20230717 (https://download.01.org/0day-ci/archive/20230717/202307170435.p9l0j6zC-lkp@…) > compiler: or1k-linux-gcc (GCC) 12.3.0 > reproduce: (https://download.01.org/0day-ci/archive/20230717/202307170435.p9l0j6zC-lkp@…) [...] > drivers/android/binder.c: Assembler messages: > >> drivers/android/binder.c:3355: Error: unrecognized keyword/register name `l.lwz ?ap,4(r20)' > drivers/android/binder.c:3360: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' > drivers/android/binder.c:3427: Error: unrecognized keyword/register name `l.lwz ?ap,4(r20)' > drivers/android/binder.c:3432: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' > >> drivers/android/binder.c:3555: Error: unrecognized keyword/register name `l.lwz ?ap,4(r21)' > drivers/android/binder.c:3560: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' Probably same issue as https://lore.kernel.org/oe-kbuild-all/202010160523.r8yMbvrW-lkp@intel.com/ ? That thread says the fix is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/a… , and it was then backported to 5.4 (as a6db3aab9c408e1b788c43f9fb179382f5793ea2) and 5.8.

1 year, 9 months

1
1
0 0

Projekt e-sklepu do akceptacji

by Kamil Durjasz

Dzień dobry, od wielu lat tworzymy sklepy internetowe dla firm z różnych branż, które działają jak wirtualny przedstawiciel handlowy 24 godziny na dobę, siedem dni w tygodniu. Nasz model działania sprawia, że nasi Klienci otrzymują więcej niż dotychczas zapytań ofertowych z e-sklepu. Jest szansa, abyśmy mogli porozmawiać na temat możliwości stworzenia dla Państwa tego typu projektu? Z pozdrowieniami Kamil Durjasz

1 year, 9 months

1
0
0 0

[PATCH] nvme-pci: Add quirk for Samsung PM9B1 256G and 512G SSD

by Nils Kruse

Add a quirk for Samsung PM9B1 256G and 512G that reports duplicate ids for disk. Signed-off-by: Nils Kruse <nilskruse97(a)gmail.com> --- drivers/nvme/host/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 60f51155a6d2..de5e4c7e4bc9 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3395,7 +3395,8 @@ static const struct pci_device_id nvme_id_table[] = { { PCI_DEVICE(0x1d97, 0x2263), /* SPCC */ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, { PCI_DEVICE(0x144d, 0xa80b), /* Samsung PM9B1 256G and 512G */ - .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES | + NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(0x144d, 0xa809), /* Samsung MZALQ256HBJD 256G */ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, { PCI_DEVICE(0x1cc4, 0x6303), /* UMIS RPJTJ512MGE1QDY 512G */ -- 2.41.0

1 year, 9 months

3
3
0 0

[PATCH] ARM: dts: exynos/i9100: Fix LCD screen's physical size

by Paul Cercueil

The previous values were completely bogus, and resulted in the computed DPI ratio being much lower than reality, causing applications and UIs to misbehave. The new values were measured by myself with a ruler. Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Acked-by: Sam Ravnborg <sam(a)ravnborg.org> Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Cc: <stable(a)vger.kernel.org> # v5.8+ --- arch/arm/boot/dts/samsung/exynos4210-i9100.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts index 37cd4dde53e4..a9ec1f6c1dea 100644 --- a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts +++ b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts @@ -207,8 +207,8 @@ lcd@0 { power-on-delay = <10>; reset-delay = <10>; - panel-width-mm = <90>; - panel-height-mm = <154>; + panel-width-mm = <56>; + panel-height-mm = <93>; display-timings { timing { -- 2.40.1

1 year, 9 months

2
2
0 0

[PATCH] exfat: check if filename entries exceeds max filename length

by Namjae Jeon

exfat_extract_uni_name copies characters from a given file name entry into the 'uniname' variable. This variable is actually defined on the stack of the exfat_readdir() function. According to the definition of the 'exfat_uni_name' type, the file name should be limited 255 characters (+ null teminator space), but the exfat_get_uniname_from_ext_entry() function can write more characters because there is no check if filename entries exceeds max filename length. This patch add the check not to copy filename characters when exceeding max filename length. Cc: stable(a)vger.kernel.org Cc: Yuezhang Mo <Yuezhang.Mo(a)sony.com> Reported-by: Maxim Suhanov <dfirblog(a)gmail.com> Reviewed-by: Sungjong Seo <sj1557.seo(a)samsung.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> --- fs/exfat/dir.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index 957574180a5e..bc48f3329921 100644 --- a/fs/exfat/dir.c +++ b/fs/exfat/dir.c @@ -34,6 +34,7 @@ static int exfat_get_uniname_from_ext_entry(struct super_block *sb, { int i, err; struct exfat_entry_set_cache es; + unsigned int uni_len = 0, len; err = exfat_get_dentry_set(&es, sb, p_dir, entry, ES_ALL_ENTRIES); if (err) @@ -52,7 +53,10 @@ static int exfat_get_uniname_from_ext_entry(struct super_block *sb, if (exfat_get_entry_type(ep) != TYPE_EXTEND) break; - exfat_extract_uni_name(ep, uniname); + len = exfat_extract_uni_name(ep, uniname); + uni_len += len; + if (len != EXFAT_FILE_NAME_LEN || uni_len >= MAX_NAME_LENGTH) + break; uniname += EXFAT_FILE_NAME_LEN; } @@ -1079,7 +1083,8 @@ int exfat_find_dir_entry(struct super_block *sb, struct exfat_inode_info *ei, if (entry_type == TYPE_EXTEND) { unsigned short entry_uniname[16], unichar; - if (step != DIRENT_STEP_NAME) { + if (step != DIRENT_STEP_NAME || + name_len >= MAX_NAME_LENGTH) { step = DIRENT_STEP_FILE; continue; } -- 2.25.1

1 year, 9 months

2
1
0 0

[PATCH 5.15] ovl: fix null pointer dereference in ovl_get_acl_rcu()

by Zhihao Cheng

[ Upstream commit f4e19e595cc2e76a8a58413eb19d3d9c51328b53 ] Following process: P1 P2 path_openat link_path_walk may_lookup inode_permission(rcu) ovl_permission acl_permission_check check_acl get_cached_acl_rcu ovl_get_inode_acl realinode = ovl_inode_real(ovl_inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL ovl_inode_upper upperdentry = ovl_i_dentry_upper(ovl_inode) d_inode(upperdentry) // returns NULL IS_POSIXACL(realinode) // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 205.472797] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted 6.3.0-12064-g2edfa098e750-dirty #1216 [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300 [ 205.489584] Call Trace: [ 205.489812] <TASK> [ 205.490014] ovl_get_inode_acl+0x26/0x30 [ 205.490466] get_cached_acl_rcu+0x61/0xa0 [ 205.490908] generic_permission+0x1bf/0x4e0 [ 205.491447] ovl_permission+0x79/0x1b0 [ 205.491917] inode_permission+0x15e/0x2c0 [ 205.492425] link_path_walk+0x115/0x550 [ 205.493311] path_lookupat.isra.0+0xb2/0x200 [ 205.493803] filename_lookup+0xda/0x240 [ 205.495747] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking. There are some changes from upstream commit: 1. Corrusponds to do_ovl_get_acl() in 5.15 is ovl_get_acl() 2. ovl_i_path_real is not imported in 5.15, we can get realinode by ovl_inode_real 3. CONFIG_FS_POSIX_ACL checking is dropped in commit ded536561a3674327dfa4bb389085705cae22b8a ("ovl: improve ovl_get_acl() if POSIX ACL support is off"), we still keep it in 5.15. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217404 Fixes: 332f606b32b6 ("ovl: enable RCU'd ->get_acl()") Cc: <stable(a)vger.kernel.org> # v5.15 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Suggested-by: Christian Brauner <brauner(a)kernel.org> Suggested-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> --- fs/overlayfs/inode.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index d41f0c8e0e2a..65e5e6eb761a 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -453,7 +453,15 @@ struct posix_acl *ovl_get_acl(struct inode *inode, int type, bool rcu) const struct cred *old_cred; struct posix_acl *acl; - if (!IS_ENABLED(CONFIG_FS_POSIX_ACL) || !IS_POSIXACL(realinode)) + if (!IS_ENABLED(CONFIG_FS_POSIX_ACL)) + return NULL; + + if (!realinode) { + WARN_ON(!rcu); + return ERR_PTR(-ECHILD); + } + + if (!IS_POSIXACL(realinode)) return NULL; if (rcu) -- 2.39.2

1 year, 9 months

3
3
0 0

Re: [PATCH 6.4 000/800] 6.4.4-rc1 review

by Ronald Warsow

Hi Greg 6.4.4-rc1 compiles, boots and runs here on x86_64 (Intel Rocket Lake, i5-11400) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 year, 9 months

1
0
0 0

[PATCH -stable v5.10 0/3] Fixes for rcutorture TRACE02 warning

by Joel Fernandes (Google)

These patches required to prevent the following TRACE02 warning when running rcutorture. I confirmed the patch fixes the following splat: [ 765.941351] WARNING: CPU: 0 PID: 80 at kernel/rcu/tasks.h:895 trc_read_check_handler+0x61/0xe0 [ 765.949880] Modules linked in: [ 765.953006] CPU: 0 PID: 80 Comm: rcu_torture_rea Not tainted 5.15.86-rc1+ #25 [ 765.959982] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 765.967964] RIP: 0010:trc_read_check_handler+0x61/0xe0 [ 765.973050] Code: 01 00 89 c0 48 03 2c c5 80 f8 a5 ae c6 45 00 00 [..] [ 765.991768] RSP: 0000:ffffa64ac0003fb0 EFLAGS: 00010047 [ 765.997042] RAX: ffffffffad4f8610 RBX: ffffa26b41bd3000 RCX: ffffa26b5f4ac8c0 [ 766.004418] RDX: 0000000000000000 RSI: ffffffffae978121 RDI: ffffa26b41bd3000 [ 766.011502] RBP: ffffa26b41bd6000 R08: ffffa26b41bd3000 R09: 0000000000000000 [ 766.018778] R10: 0000000000000000 R11: ffffa64ac0003ff8 R12: 0000000000000000 [ 766.025943] R13: ffffa26b5f4ac8c0 R14: 0000000000000000 R15: 0000000000000000 [ 766.034383] FS: 0000000000000000(0000) GS:ffffa26b5f400000(0000) knlGS:0000000000000000 [ 766.042925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 766.048775] CR2: 0000000000000000 CR3: 0000000001924000 CR4: 00000000000006f0 [ 766.055991] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 766.063135] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 766.070711] Call Trace: [ 766.073515] <IRQ> [ 766.075807] flush_smp_call_function_queue+0xec/0x1a0 [ 766.081087] __sysvec_call_function_single+0x3e/0x1d0 [ 766.086466] sysvec_call_function_single+0x89/0xc0 [ 766.091431] </IRQ> [ 766.093713] <TASK> [ 766.095930] asm_sysvec_call_function_single+0x16/0x20

1 year, 9 months

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2023