- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] hfsplus: fix uninit-value in copy_name
by Wenyu Huang 03 Aug '24

03 Aug '24

From: Edward Adam Davis <eadavis(a)qq.com> [Backport] hfsplus: fix uninit-value in copy_name stable inclusion from stable-v4.19.319 commit 72805debec8f7aa342da194fe0ed7bc8febea335 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELD CVE: CVE-2024-41059 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0570730c16307a72f8241df12363f76600baf57d ] [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0. Reported-and-tested-by: syzbot+efde959319469ff8d4d7(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Link: https://lore.kernel.org/r/tencent_8BBB6433BC9E1C1B7B4BDF1BF52574BA8808@qq.c… Reported-and-tested-by: syzbot+01ade747b16e9c8030e0(a)syzkaller.appspotmail.com Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wenyu Huang <huangwenyu5(a)huawei.com> --- fs/hfsplus/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c index d5403b4004c97..cf8647a4c35bd 100644 --- a/fs/hfsplus/xattr.c +++ b/fs/hfsplus/xattr.c @@ -700,7 +700,7 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size) return err; } - strbuf = kmalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN + + strbuf = kzalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN + XATTR_MAC_OSX_PREFIX_LEN + 1, GFP_KERNEL); if (!strbuf) { res = -ENOMEM; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-41062
by Zhengchao Shao 03 Aug '24

03 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (1): Bluetooth: L2CAP: Fix deadlock net/bluetooth/l2cap_core.c | 3 +++ net/bluetooth/l2cap_sock.c | 10 +++++++++- 2 files changed, 12 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] fix CVE-2024-41062
by Zhengchao Shao 03 Aug '24

03 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (1): Bluetooth: L2CAP: Fix deadlock net/bluetooth/l2cap_core.c | 3 +++ net/bluetooth/l2cap_sock.c | 10 +++++++++- 2 files changed, 12 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-5.10] ata: libata-core: Fix double free on error
by Li Lingfeng 03 Aug '24

03 Aug '24

From: Niklas Cassel <cassel(a)kernel.org> stable inclusion from stable-v5.10.221 commit 010de9acbea58fbcbda08e3793d6262086a493fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGENX CVE: CVE-2024-41087 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit ab9e0c529eb7cafebdd31fe1644524e80a48b05d upstream. If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed. Fixes: dafd6c496381 ("libata: ensure host is free'd on error exit paths") Cc: stable(a)vger.kernel.org Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Link: https://lore.kernel.org/r/20240629124210.181537-9-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/ata/libata-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 702b8e061b36..3717ed6fcccc 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -5420,8 +5420,10 @@ struct ata_host *ata_host_alloc(struct device *dev, int max_ports) if (!host) return NULL; - if (!devres_open_group(dev, NULL, GFP_KERNEL)) - goto err_free; + if (!devres_open_group(dev, NULL, GFP_KERNEL)) { + kfree(host); + return NULL; + } dr = devres_alloc(ata_devres_release, 0, GFP_KERNEL); if (!dr) @@ -5453,8 +5455,6 @@ struct ata_host *ata_host_alloc(struct device *dev, int max_ports) err_out: devres_release_group(dev, NULL); - err_free: - kfree(host); return NULL; } EXPORT_SYMBOL_GPL(ata_host_alloc); -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] ata: libata-core: Fix double free on error
by Li Lingfeng 03 Aug '24

03 Aug '24

From: Niklas Cassel <cassel(a)kernel.org> stable inclusion from stable-v4.19.317 commit 290073b2b557e4dc21ee74a1e403d9ae79e393a2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGENX CVE: CVE-2024-41087 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit ab9e0c529eb7cafebdd31fe1644524e80a48b05d upstream. If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed. Fixes: dafd6c496381 ("libata: ensure host is free'd on error exit paths") Cc: stable(a)vger.kernel.org Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Link: https://lore.kernel.org/r/20240629124210.181537-9-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/ata/libata-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index e685162a188e..e23ba7e4298d 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -6195,8 +6195,10 @@ struct ata_host *ata_host_alloc(struct device *dev, int max_ports) if (!host) return NULL; - if (!devres_open_group(dev, NULL, GFP_KERNEL)) - goto err_free; + if (!devres_open_group(dev, NULL, GFP_KERNEL)) { + kfree(host); + return NULL; + } dr = devres_alloc(ata_devres_release, 0, GFP_KERNEL); if (!dr) @@ -6228,8 +6230,6 @@ struct ata_host *ata_host_alloc(struct device *dev, int max_ports) err_out: devres_release_group(dev, NULL); - err_free: - kfree(host); return NULL; } -- 2.31.1

2 1

[PATCH OLK-6.6] leds: mlxreg: Use devm_mutex_init() for mutex initialization
by Tengda Wu 03 Aug '24

03 Aug '24

From: George Stark <gnstark(a)salutedevices.com> mainline inclusion from mainline-v6.10-rc1 commit efc347b9efee1c2b081f5281d33be4559fa50a16 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGS4V CVE: CVE-2024-42129 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: George Stark <gnstark(a)salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee(a)kernel.org> Fixes: 386570d76f2f ("leds: add driver for support Mellanox regmap LEDs for BMC and x86 platform") Conflicts: drivers/leds/leds-mlxreg.c [This is because we did not backport 606130209230 ("leds: Convert all platform drivers to return void")] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/leds/leds-mlxreg.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c index 39210653acf7..b1510cd32e47 100644 --- a/drivers/leds/leds-mlxreg.c +++ b/drivers/leds/leds-mlxreg.c @@ -257,6 +257,7 @@ static int mlxreg_led_probe(struct platform_device *pdev) { struct mlxreg_core_platform_data *led_pdata; struct mlxreg_led_priv_data *priv; + int err; led_pdata = dev_get_platdata(&pdev->dev); if (!led_pdata) { @@ -268,28 +269,21 @@ static int mlxreg_led_probe(struct platform_device *pdev) if (!priv) return -ENOMEM; - mutex_init(&priv->access_lock); + err = devm_mutex_init(&pdev->dev, &priv->access_lock); + if (err) + return err; + priv->pdev = pdev; priv->pdata = led_pdata; return mlxreg_led_config(priv); } -static int mlxreg_led_remove(struct platform_device *pdev) -{ - struct mlxreg_led_priv_data *priv = dev_get_drvdata(&pdev->dev); - - mutex_destroy(&priv->access_lock); - - return 0; -} - static struct platform_driver mlxreg_led_driver = { .driver = { .name = "leds-mlxreg", }, .probe = mlxreg_led_probe, - .remove = mlxreg_led_remove, }; module_platform_driver(mlxreg_led_driver); -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] fix CVE-2024-42129
by Tengda Wu 03 Aug '24

03 Aug '24

This patch set is going to fix CVE-2024-42129. George Stark (2): locking/mutex: Introduce devm_mutex_init() leds: mlxreg: Use devm_mutex_init() for mutex initialization drivers/leds/leds-mlxreg.c | 16 +++++----------- include/linux/mutex.h | 27 +++++++++++++++++++++++++++ kernel/locking/mutex-debug.c | 12 ++++++++++++ 3 files changed, 44 insertions(+), 11 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-42129
by Tengda Wu 03 Aug '24

03 Aug '24

This patch set is going to fix CVE-2024-42129. George Stark (2): locking/mutex: Introduce devm_mutex_init() leds: mlxreg: Use devm_mutex_init() for mutex initialization drivers/leds/leds-mlxreg.c | 16 +++++----------- include/linux/mutex.h | 27 +++++++++++++++++++++++++++ kernel/locking/mutex-debug.c | 12 ++++++++++++ 3 files changed, 44 insertions(+), 11 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-42155
by Hongbo Li 03 Aug '24

03 Aug '24

Fix CVE-2024-42155. Holger Dengler (1): s390/pkey: Wipe copies of protected- and secure-keys drivers/s390/crypto/pkey_api.c | 80 ++++++++++++++++------------------ 1 file changed, 37 insertions(+), 43 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
by Li Huafei 03 Aug '24

03 Aug '24

From: Alan Stern <stern(a)rowland.harvard.edu> commit a368ecde8a5055b627749b09c6218ef793043e47 upstream. Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-and-tested-by: syzbot+8693a0bb9c10b554272a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/ Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") CC: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/usb/core/config.c [ Resolved context conflict due to commit 63d176ed148a ("USB: core: add endpoint-blacklist quirk") not backport. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/usb/core/config.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 9fa70894179c..4781eebefd20 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -290,6 +290,20 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, if (ifp->desc.bNumEndpoints >= num_ep) goto skip_to_next_endpoint_or_interface_descriptor; + /* Save a copy of the descriptor and use it instead of the original */ + endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + memcpy(&endpoint->desc, d, n); + d = &endpoint->desc; + + /* Clear the reserved bits in bEndpointAddress */ + i = d->bEndpointAddress & + (USB_ENDPOINT_DIR_MASK | USB_ENDPOINT_NUMBER_MASK); + if (i != d->bEndpointAddress) { + dev_notice(ddev, "config %d interface %d altsetting %d has an endpoint descriptor with address 0x%X, changing to 0x%X\n", + cfgno, inum, asnum, d->bEndpointAddress, i); + endpoint->desc.bEndpointAddress = i; + } + /* Check for duplicate endpoint addresses */ if (config_endpoint_is_duplicate(config, inum, asnum, d)) { dev_warn(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n", @@ -297,10 +311,8 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, goto skip_to_next_endpoint_or_interface_descriptor; } - endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + /* Accept this endpoint */ ++ifp->desc.bNumEndpoints; - - memcpy(&endpoint->desc, d, n); INIT_LIST_HEAD(&endpoint->urb_list); /* -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
by Li Huafei 03 Aug '24

03 Aug '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.222 commit d09dd21bb5215d583ca9a1cb1464dbc77a7e88cf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN0 CVE: CVE-2024-41035 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a368ecde8a5055b627749b09c6218ef793043e47 upstream. Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-and-tested-by: syzbot+8693a0bb9c10b554272a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/ Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") CC: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/usb/core/config.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 2f8a1225b697..1508e0f00dbc 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -291,6 +291,20 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, if (ifp->desc.bNumEndpoints >= num_ep) goto skip_to_next_endpoint_or_interface_descriptor; + /* Save a copy of the descriptor and use it instead of the original */ + endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + memcpy(&endpoint->desc, d, n); + d = &endpoint->desc; + + /* Clear the reserved bits in bEndpointAddress */ + i = d->bEndpointAddress & + (USB_ENDPOINT_DIR_MASK | USB_ENDPOINT_NUMBER_MASK); + if (i != d->bEndpointAddress) { + dev_notice(ddev, "config %d interface %d altsetting %d has an endpoint descriptor with address 0x%X, changing to 0x%X\n", + cfgno, inum, asnum, d->bEndpointAddress, i); + endpoint->desc.bEndpointAddress = i; + } + /* Check for duplicate endpoint addresses */ if (config_endpoint_is_duplicate(config, inum, asnum, d)) { dev_notice(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n", @@ -308,10 +322,8 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, } } - endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + /* Accept this endpoint */ ++ifp->desc.bNumEndpoints; - - memcpy(&endpoint->desc, d, n); INIT_LIST_HEAD(&endpoint->urb_list); /* -- 2.25.1

2 1

[PATCH OLK-5.10] USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
by Li Huafei 03 Aug '24

03 Aug '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.222 commit d09dd21bb5215d583ca9a1cb1464dbc77a7e88cf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN0 CVE: CVE-2024-41035 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a368ecde8a5055b627749b09c6218ef793043e47 upstream. Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-and-tested-by: syzbot+8693a0bb9c10b554272a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/ Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") CC: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/usb/core/config.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 2f8a1225b697..1508e0f00dbc 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -291,6 +291,20 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, if (ifp->desc.bNumEndpoints >= num_ep) goto skip_to_next_endpoint_or_interface_descriptor; + /* Save a copy of the descriptor and use it instead of the original */ + endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + memcpy(&endpoint->desc, d, n); + d = &endpoint->desc; + + /* Clear the reserved bits in bEndpointAddress */ + i = d->bEndpointAddress & + (USB_ENDPOINT_DIR_MASK | USB_ENDPOINT_NUMBER_MASK); + if (i != d->bEndpointAddress) { + dev_notice(ddev, "config %d interface %d altsetting %d has an endpoint descriptor with address 0x%X, changing to 0x%X\n", + cfgno, inum, asnum, d->bEndpointAddress, i); + endpoint->desc.bEndpointAddress = i; + } + /* Check for duplicate endpoint addresses */ if (config_endpoint_is_duplicate(config, inum, asnum, d)) { dev_notice(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n", @@ -308,10 +322,8 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, } } - endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + /* Accept this endpoint */ ++ifp->desc.bNumEndpoints; - - memcpy(&endpoint->desc, d, n); INIT_LIST_HEAD(&endpoint->urb_list); /* -- 2.25.1

2 1

[PATCH OLK-6.6] USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
by Li Huafei 03 Aug '24

03 Aug '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.6.41 commit 647d61aef106dbed9c70447bcddbd4968e67ca64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN0 CVE: CVE-2024-41035 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a368ecde8a5055b627749b09c6218ef793043e47 upstream. Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-and-tested-by: syzbot+8693a0bb9c10b554272a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/ Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") CC: Oliver Neukum <oneukum(a)suse.com> CC: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/usb/core/config.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 7f8d33f92ddb..847dd32c0f5e 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -291,6 +291,20 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, if (ifp->desc.bNumEndpoints >= num_ep) goto skip_to_next_endpoint_or_interface_descriptor; + /* Save a copy of the descriptor and use it instead of the original */ + endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + memcpy(&endpoint->desc, d, n); + d = &endpoint->desc; + + /* Clear the reserved bits in bEndpointAddress */ + i = d->bEndpointAddress & + (USB_ENDPOINT_DIR_MASK | USB_ENDPOINT_NUMBER_MASK); + if (i != d->bEndpointAddress) { + dev_notice(ddev, "config %d interface %d altsetting %d has an endpoint descriptor with address 0x%X, changing to 0x%X\n", + cfgno, inum, asnum, d->bEndpointAddress, i); + endpoint->desc.bEndpointAddress = i; + } + /* Check for duplicate endpoint addresses */ if (config_endpoint_is_duplicate(config, inum, asnum, d)) { dev_notice(ddev, "config %d interface %d altsetting %d has a duplicate endpoint with address 0x%X, skipping\n", @@ -308,10 +322,8 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, } } - endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints]; + /* Accept this endpoint */ ++ifp->desc.bNumEndpoints; - - memcpy(&endpoint->desc, d, n); INIT_LIST_HEAD(&endpoint->urb_list); /* -- 2.25.1

2 1

[PATCH OLK-5.10] can: mcp251xfd: fix infinite loop when xmit fails
by Liu Jian 03 Aug '24

03 Aug '24

From: Vitor Soares <vitor.soares(a)toradex.com> mainline inclusion from mainline-v6.10-rc6 commit d8fb63e46c884c898a38f061c2330f7729e75510 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGENL CVE: CVE-2024-41088 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable(a)vger.kernel.org Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> Link: https://lore.kernel.org/all/20240517134355.770777-1-ivitro@gmail.com [mkl: use more imperative wording in patch description] Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Conflicts: drivers/net/can/spi/mcp251xfd/mcp251xfd-tx.c drivers/net/can/spi/mcp251xfd/mcp251xfd.h [Mainly because we did not backport 09b0eb92fec7 ("can: mcp251xfd: move TX handling into separate file"), f318482a1c57 ("can: dev: can_free_echo_skb(): extend to return can frame length").] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- .../net/can/spi/mcp251xfd/mcp251xfd-core.c | 69 ++++++++++++++++--- drivers/net/can/spi/mcp251xfd/mcp251xfd.h | 4 ++ 2 files changed, 64 insertions(+), 9 deletions(-) diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c index 189d22658813..53049c60e953 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c @@ -2304,6 +2304,39 @@ mcp251xfd_tx_obj_from_skb(const struct mcp251xfd_priv *priv, tx_obj->xfer[0].len = len; } +static void mcp251xfd_tx_failure_drop(const struct mcp251xfd_priv *priv, + struct mcp251xfd_tx_ring *tx_ring, + int err) +{ + struct net_device *ndev = priv->ndev; + struct net_device_stats *stats = &ndev->stats; + unsigned int frame_len = 0; + u8 tx_head; + + tx_ring->head--; + stats->tx_dropped++; + tx_head = mcp251xfd_get_tx_head(tx_ring); + can_free_echo_skb(ndev, tx_head); + netdev_completed_queue(ndev, 1, frame_len); + netif_wake_queue(ndev); + + if (net_ratelimit()) + netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err); +} + +void mcp251xfd_tx_obj_write_sync(struct work_struct *work) +{ + struct mcp251xfd_priv *priv = container_of(work, struct mcp251xfd_priv, + tx_work); + struct mcp251xfd_tx_obj *tx_obj = priv->tx_work_obj; + struct mcp251xfd_tx_ring *tx_ring = priv->tx; + int err; + + err = spi_sync(priv->spi, &tx_obj->msg); + if (err) + mcp251xfd_tx_failure_drop(priv, tx_ring, err); +} + static int mcp251xfd_tx_obj_write(const struct mcp251xfd_priv *priv, struct mcp251xfd_tx_obj *tx_obj) { @@ -2335,6 +2368,11 @@ static bool mcp251xfd_tx_busy(const struct mcp251xfd_priv *priv, return false; } +static bool mcp251xfd_work_busy(struct work_struct *work) +{ + return work_busy(work); +} + static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, struct net_device *ndev) { @@ -2347,7 +2385,8 @@ static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, if (can_dropped_invalid_skb(ndev, skb)) return NETDEV_TX_OK; - if (mcp251xfd_tx_busy(priv, tx_ring)) + if (mcp251xfd_tx_busy(priv, tx_ring) || + mcp251xfd_work_busy(&priv->tx_work)) return NETDEV_TX_BUSY; tx_obj = mcp251xfd_get_tx_obj_next(tx_ring); @@ -2362,13 +2401,13 @@ static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, can_put_echo_skb(skb, ndev, tx_head); err = mcp251xfd_tx_obj_write(priv, tx_obj); - if (err) - goto out_err; - - return NETDEV_TX_OK; - - out_err: - netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err); + if (err == -EBUSY) { + netif_stop_queue(ndev); + priv->tx_work_obj = tx_obj; + queue_work(priv->wq, &priv->tx_work); + } else if (err) { + mcp251xfd_tx_failure_drop(priv, tx_ring, err); + } return NETDEV_TX_OK; } @@ -2403,11 +2442,20 @@ static int mcp251xfd_open(struct net_device *ndev) can_rx_offload_enable(&priv->offload); + priv->wq = alloc_ordered_workqueue("%s-mcp251xfd_wq", + WQ_FREEZABLE | WQ_MEM_RECLAIM, + dev_name(&spi->dev)); + if (!priv->wq) { + err = -ENOMEM; + goto out_can_rx_offload_disable; + } + INIT_WORK(&priv->tx_work, mcp251xfd_tx_obj_write_sync); + err = request_threaded_irq(spi->irq, NULL, mcp251xfd_irq, IRQF_ONESHOT, dev_name(&spi->dev), priv); if (err) - goto out_can_rx_offload_disable; + goto out_destroy_workqueue; err = mcp251xfd_chip_interrupts_enable(priv); if (err) @@ -2419,6 +2467,8 @@ static int mcp251xfd_open(struct net_device *ndev) out_free_irq: free_irq(spi->irq, priv); + out_destroy_workqueue: + destroy_workqueue(priv->wq); out_can_rx_offload_disable: can_rx_offload_disable(&priv->offload); out_transceiver_disable: @@ -2441,6 +2491,7 @@ static int mcp251xfd_stop(struct net_device *ndev) netif_stop_queue(ndev); mcp251xfd_chip_interrupts_disable(priv); free_irq(ndev->irq, priv); + destroy_workqueue(priv->wq); can_rx_offload_disable(&priv->offload); mcp251xfd_chip_stop(priv, CAN_STATE_STOPPED); mcp251xfd_transceiver_disable(priv); diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h index 766dbd19bba6..28af0dd5225f 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h @@ -584,6 +584,10 @@ struct mcp251xfd_priv { struct mcp251xfd_tx_ring tx[1]; struct mcp251xfd_rx_ring *rx[1]; + struct workqueue_struct *wq; + struct work_struct tx_work; + struct mcp251xfd_tx_obj *tx_work_obj; + u8 rx_ring_num; struct mcp251xfd_ecc ecc; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] can: mcp251xfd: fix infinite loop when xmit fails
by Liu Jian 03 Aug '24

03 Aug '24

From: Vitor Soares <vitor.soares(a)toradex.com> mainline inclusion from mainline-v6.10-rc6 commit d8fb63e46c884c898a38f061c2330f7729e75510 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGENL CVE: CVE-2024-41088 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable(a)vger.kernel.org Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> Link: https://lore.kernel.org/all/20240517134355.770777-1-ivitro@gmail.com [mkl: use more imperative wording in patch description] Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Conflicts: drivers/net/can/spi/mcp251xfd/mcp251xfd-tx.c drivers/net/can/spi/mcp251xfd/mcp251xfd.h [Mainly because we did not backport 09b0eb92fec7 ("can: mcp251xfd: move TX handling into separate file"), f318482a1c57 ("can: dev: can_free_echo_skb(): extend to return can frame length").] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- .../net/can/spi/mcp251xfd/mcp251xfd-core.c | 69 ++++++++++++++++--- drivers/net/can/spi/mcp251xfd/mcp251xfd.h | 4 ++ 2 files changed, 64 insertions(+), 9 deletions(-) diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c index 189d22658813..53049c60e953 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c @@ -2304,6 +2304,39 @@ mcp251xfd_tx_obj_from_skb(const struct mcp251xfd_priv *priv, tx_obj->xfer[0].len = len; } +static void mcp251xfd_tx_failure_drop(const struct mcp251xfd_priv *priv, + struct mcp251xfd_tx_ring *tx_ring, + int err) +{ + struct net_device *ndev = priv->ndev; + struct net_device_stats *stats = &ndev->stats; + unsigned int frame_len = 0; + u8 tx_head; + + tx_ring->head--; + stats->tx_dropped++; + tx_head = mcp251xfd_get_tx_head(tx_ring); + can_free_echo_skb(ndev, tx_head); + netdev_completed_queue(ndev, 1, frame_len); + netif_wake_queue(ndev); + + if (net_ratelimit()) + netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err); +} + +void mcp251xfd_tx_obj_write_sync(struct work_struct *work) +{ + struct mcp251xfd_priv *priv = container_of(work, struct mcp251xfd_priv, + tx_work); + struct mcp251xfd_tx_obj *tx_obj = priv->tx_work_obj; + struct mcp251xfd_tx_ring *tx_ring = priv->tx; + int err; + + err = spi_sync(priv->spi, &tx_obj->msg); + if (err) + mcp251xfd_tx_failure_drop(priv, tx_ring, err); +} + static int mcp251xfd_tx_obj_write(const struct mcp251xfd_priv *priv, struct mcp251xfd_tx_obj *tx_obj) { @@ -2335,6 +2368,11 @@ static bool mcp251xfd_tx_busy(const struct mcp251xfd_priv *priv, return false; } +static bool mcp251xfd_work_busy(struct work_struct *work) +{ + return work_busy(work); +} + static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, struct net_device *ndev) { @@ -2347,7 +2385,8 @@ static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, if (can_dropped_invalid_skb(ndev, skb)) return NETDEV_TX_OK; - if (mcp251xfd_tx_busy(priv, tx_ring)) + if (mcp251xfd_tx_busy(priv, tx_ring) || + mcp251xfd_work_busy(&priv->tx_work)) return NETDEV_TX_BUSY; tx_obj = mcp251xfd_get_tx_obj_next(tx_ring); @@ -2362,13 +2401,13 @@ static netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb, can_put_echo_skb(skb, ndev, tx_head); err = mcp251xfd_tx_obj_write(priv, tx_obj); - if (err) - goto out_err; - - return NETDEV_TX_OK; - - out_err: - netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err); + if (err == -EBUSY) { + netif_stop_queue(ndev); + priv->tx_work_obj = tx_obj; + queue_work(priv->wq, &priv->tx_work); + } else if (err) { + mcp251xfd_tx_failure_drop(priv, tx_ring, err); + } return NETDEV_TX_OK; } @@ -2403,11 +2442,20 @@ static int mcp251xfd_open(struct net_device *ndev) can_rx_offload_enable(&priv->offload); + priv->wq = alloc_ordered_workqueue("%s-mcp251xfd_wq", + WQ_FREEZABLE | WQ_MEM_RECLAIM, + dev_name(&spi->dev)); + if (!priv->wq) { + err = -ENOMEM; + goto out_can_rx_offload_disable; + } + INIT_WORK(&priv->tx_work, mcp251xfd_tx_obj_write_sync); + err = request_threaded_irq(spi->irq, NULL, mcp251xfd_irq, IRQF_ONESHOT, dev_name(&spi->dev), priv); if (err) - goto out_can_rx_offload_disable; + goto out_destroy_workqueue; err = mcp251xfd_chip_interrupts_enable(priv); if (err) @@ -2419,6 +2467,8 @@ static int mcp251xfd_open(struct net_device *ndev) out_free_irq: free_irq(spi->irq, priv); + out_destroy_workqueue: + destroy_workqueue(priv->wq); out_can_rx_offload_disable: can_rx_offload_disable(&priv->offload); out_transceiver_disable: @@ -2441,6 +2491,7 @@ static int mcp251xfd_stop(struct net_device *ndev) netif_stop_queue(ndev); mcp251xfd_chip_interrupts_disable(priv); free_irq(ndev->irq, priv); + destroy_workqueue(priv->wq); can_rx_offload_disable(&priv->offload); mcp251xfd_chip_stop(priv, CAN_STATE_STOPPED); mcp251xfd_transceiver_disable(priv); diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h index 766dbd19bba6..28af0dd5225f 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h @@ -584,6 +584,10 @@ struct mcp251xfd_priv { struct mcp251xfd_tx_ring tx[1]; struct mcp251xfd_rx_ring *rx[1]; + struct workqueue_struct *wq; + struct work_struct tx_work; + struct mcp251xfd_tx_obj *tx_work_obj; + u8 rx_ring_num; struct mcp251xfd_ecc ecc; -- 2.34.1

2 1

[PATCH OLK-5.10] wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v5.10.223 commit 6295bad58f988eaafcf0e6f8b198a580398acb3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELZ CVE: CVE-2024-41072 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 6ef09cdc5ba0f93826c09d810c141a8d103a80fc ] In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise. Reported-by: syzbot+253cd2d2491df77c93ac(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=253cd2d2491df77c93ac Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Link: https://msgid.link/20240531032010.451295-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/scan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index a6c289a61d30..76a27b6d45d2 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -2772,10 +2772,14 @@ int cfg80211_wext_siwscan(struct net_device *dev, wiphy = &rdev->wiphy; /* Determine number of channels, needed to allocate creq */ - if (wreq && wreq->num_channels) + if (wreq && wreq->num_channels) { + /* Passed from userspace so should be checked */ + if (unlikely(wreq->num_channels > IW_MAX_FREQUENCIES)) + return -EINVAL; n_channels = wreq->num_channels; - else + } else { n_channels = ieee80211_get_num_supported_channels(wiphy); + } creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) + n_channels * sizeof(void *), -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v5.10.223 commit 6295bad58f988eaafcf0e6f8b198a580398acb3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELZ CVE: CVE-2024-41072 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 6ef09cdc5ba0f93826c09d810c141a8d103a80fc ] In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise. Reported-by: syzbot+253cd2d2491df77c93ac(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=253cd2d2491df77c93ac Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Link: https://msgid.link/20240531032010.451295-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/scan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index 22d169923261..729d8e089db1 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -2721,10 +2721,14 @@ int cfg80211_wext_siwscan(struct net_device *dev, wiphy = &rdev->wiphy; /* Determine number of channels, needed to allocate creq */ - if (wreq && wreq->num_channels) + if (wreq && wreq->num_channels) { + /* Passed from userspace so should be checked */ + if (unlikely(wreq->num_channels > IW_MAX_FREQUENCIES)) + return -EINVAL; n_channels = wreq->num_channels; - else + } else { n_channels = ieee80211_get_num_supported_channels(wiphy); + } creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) + n_channels * sizeof(void *), -- 2.34.1

2 1

[PATCH OLK-6.6] wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v6.6.42 commit fe9644efd86704afe50e56b64b609de340ab7c95 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELZ CVE: CVE-2024-41072 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 6ef09cdc5ba0f93826c09d810c141a8d103a80fc ] In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise. Reported-by: syzbot+253cd2d2491df77c93ac(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=253cd2d2491df77c93ac Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Link: https://msgid.link/20240531032010.451295-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/scan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index c646094a5fc4..af81cf81f68f 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -3163,10 +3163,14 @@ int cfg80211_wext_siwscan(struct net_device *dev, wiphy = &rdev->wiphy; /* Determine number of channels, needed to allocate creq */ - if (wreq && wreq->num_channels) + if (wreq && wreq->num_channels) { + /* Passed from userspace so should be checked */ + if (unlikely(wreq->num_channels > IW_MAX_FREQUENCIES)) + return -EINVAL; n_channels = wreq->num_channels; - else + } else { n_channels = ieee80211_get_num_supported_channels(wiphy); + } creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) + n_channels * sizeof(void *), -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v4.19.319 commit b02ba9a0b55b762bd04743a22f3d9f9645005e79 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELZ CVE: CVE-2024-41072 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 6ef09cdc5ba0f93826c09d810c141a8d103a80fc ] In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise. Reported-by: syzbot+253cd2d2491df77c93ac(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=253cd2d2491df77c93ac Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Link: https://msgid.link/20240531032010.451295-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/scan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index e5d61ba837ad..1ff1c12c2e81 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -1401,10 +1401,14 @@ int cfg80211_wext_siwscan(struct net_device *dev, wiphy = &rdev->wiphy; /* Determine number of channels, needed to allocate creq */ - if (wreq && wreq->num_channels) + if (wreq && wreq->num_channels) { + /* Passed from userspace so should be checked */ + if (unlikely(wreq->num_channels > IW_MAX_FREQUENCIES)) + return -EINVAL; n_channels = wreq->num_channels; - else + } else { n_channels = ieee80211_get_num_supported_channels(wiphy); + } creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) + n_channels * sizeof(void *), -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-41044
by Liu Jian 03 Aug '24

03 Aug '24

CVE-2024-41044 Dmitry Antipov (1): ppp: reject claimed-as-LCP but actually malformed packets Eric Dumazet (1): ppp: ensure minimum packet size in ppp_write() drivers/net/ppp/ppp_generic.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] sched/deadline: Fix task_struct reference leak
by Zheng Zucheng 03 Aug '24

03 Aug '24

From: Wander Lairson Costa <wander(a)redhat.com> mainline inclusion from mainline-v6.10-rc5 commit b58652db66c910c2245f5bee7deca41c12d707b9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN4 CVE: CVE-2024-41023 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During the execution of the following stress test with linux-rt: stress-ng --cyclic 30 --timeout 30 --minimize --quiet kmemleak frequently reported a memory leak concerning the task_struct: unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak. This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled. Fixes: feff2e65efd8 ("sched/deadline: Unthrottle PI boosted threads while enqueuing") Signed-off-by: Wander Lairson Costa <wander(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Juri Lelli <juri.lelli(a)redhat.com> Link: https://lore.kernel.org/r/20240620125618.11419-1-wander@redhat.com Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..e35a951a62b7 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,13 @@ static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags) * The replenish timer needs to be canceled. No * problem if it fires concurrently: boosted threads * are ignored in dl_task_timer(). + * + * If the timer callback was running (hrtimer_try_to_cancel == -1), + * it will eventually call put_task_struct(). */ - hrtimer_try_to_cancel(&p->dl.dl_timer); + if (hrtimer_try_to_cancel(&p->dl.dl_timer) == 1 && + !dl_server(&p->dl)) + put_task_struct(p); p->dl.dl_throttled = 0; } } else if (!dl_prio(p->normal_prio)) { -- 2.34.1

2 1

[PATCH OLK-6.6] sched/deadline: Fix task_struct reference leak
by Zheng Zucheng 03 Aug '24

03 Aug '24

From: Wander Lairson Costa <wander(a)redhat.com> mainline inclusion from mainline-v6.10-rc5 commit b58652db66c910c2245f5bee7deca41c12d707b9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN4 CVE: CVE-2024-41023 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During the execution of the following stress test with linux-rt: stress-ng --cyclic 30 --timeout 30 --minimize --quiet kmemleak frequently reported a memory leak concerning the task_struct: unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak. This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled. Fixes: feff2e65efd8 ("sched/deadline: Unthrottle PI boosted threads while enqueuing") Signed-off-by: Wander Lairson Costa <wander(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Juri Lelli <juri.lelli(a)redhat.com> Link: https://lore.kernel.org/r/20240620125618.11419-1-wander@redhat.com Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..e35a951a62b7 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,13 @@ static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags) * The replenish timer needs to be canceled. No * problem if it fires concurrently: boosted threads * are ignored in dl_task_timer(). + * + * If the timer callback was running (hrtimer_try_to_cancel == -1), + * it will eventually call put_task_struct(). */ - hrtimer_try_to_cancel(&p->dl.dl_timer); + if (hrtimer_try_to_cancel(&p->dl.dl_timer) == 1 && + !dl_server(&p->dl)) + put_task_struct(p); p->dl.dl_throttled = 0; } } else if (!dl_prio(p->normal_prio)) { -- 2.34.1

2 1

[PATCH OLK-5.10] sched/deadline: Fix task_struct reference leak
by Zheng Zucheng 03 Aug '24

03 Aug '24

From: Wander Lairson Costa <wander(a)redhat.com> mainline inclusion from mainline-v6.10-rc5 commit b58652db66c910c2245f5bee7deca41c12d707b9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN4 CVE: CVE-2024-41023 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During the execution of the following stress test with linux-rt: stress-ng --cyclic 30 --timeout 30 --minimize --quiet kmemleak frequently reported a memory leak concerning the task_struct: unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak. This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled. Fixes: feff2e65efd8 ("sched/deadline: Unthrottle PI boosted threads while enqueuing") Signed-off-by: Wander Lairson Costa <wander(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Juri Lelli <juri.lelli(a)redhat.com> Link: https://lore.kernel.org/r/20240620125618.11419-1-wander@redhat.com Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..e35a951a62b7 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,13 @@ static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags) * The replenish timer needs to be canceled. No * problem if it fires concurrently: boosted threads * are ignored in dl_task_timer(). + * + * If the timer callback was running (hrtimer_try_to_cancel == -1), + * it will eventually call put_task_struct(). */ - hrtimer_try_to_cancel(&p->dl.dl_timer); + if (hrtimer_try_to_cancel(&p->dl.dl_timer) == 1 && + !dl_server(&p->dl)) + put_task_struct(p); p->dl.dl_throttled = 0; } } else if (!dl_prio(p->normal_prio)) { -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] IB/core: Implement a limit on UMAD receive List
by Zhang Changzhong 03 Aug '24

03 Aug '24

From: Michael Guralnik <michaelgur(a)nvidia.com> stable inclusion from stable-v5.10.222 commit 62349fbf86b5e13b02721bdadf98c29afd1e7b5f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGSPA CVE: CVE-2024-42145 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ca0b44e20a6f3032224599f02e7c8fb49525c894 ] The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Signed-off-by: Michael Guralnik <michaelgur(a)nvidia.com> Reviewed-by: Mark Zhang <markzhang(a)nvidia.com> Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.17132688… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/infiniband/core/user_mad.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c index 4688a66..e21abd1 100644 --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -63,6 +63,8 @@ MODULE_AUTHOR("Roland Dreier"); MODULE_DESCRIPTION("InfiniBand userspace MAD packet access"); MODULE_LICENSE("Dual BSD/GPL"); +#define MAX_UMAD_RECV_LIST_SIZE 200000 + enum { IB_UMAD_MAX_PORTS = RDMA_MAX_PORTS, IB_UMAD_MAX_AGENTS = 32, @@ -113,6 +115,7 @@ struct ib_umad_file { struct mutex mutex; struct ib_umad_port *port; struct list_head recv_list; + atomic_t recv_list_size; struct list_head send_list; struct list_head port_list; spinlock_t send_lock; @@ -175,24 +178,28 @@ static struct ib_mad_agent *__get_agent(struct ib_umad_file *file, int id) return file->agents_dead ? NULL : file->agent[id]; } -static int queue_packet(struct ib_umad_file *file, - struct ib_mad_agent *agent, - struct ib_umad_packet *packet) +static int queue_packet(struct ib_umad_file *file, struct ib_mad_agent *agent, + struct ib_umad_packet *packet, bool is_recv_mad) { int ret = 1; mutex_lock(&file->mutex); + if (is_recv_mad && + atomic_read(&file->recv_list_size) > MAX_UMAD_RECV_LIST_SIZE) + goto unlock; + for (packet->mad.hdr.id = 0; packet->mad.hdr.id < IB_UMAD_MAX_AGENTS; packet->mad.hdr.id++) if (agent == __get_agent(file, packet->mad.hdr.id)) { list_add_tail(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); wake_up_interruptible(&file->recv_wait); ret = 0; break; } - +unlock: mutex_unlock(&file->mutex); return ret; @@ -219,7 +226,7 @@ static void send_handler(struct ib_mad_agent *agent, if (send_wc->status == IB_WC_RESP_TIMEOUT_ERR) { packet->length = IB_MGMT_MAD_HDR; packet->mad.hdr.status = ETIMEDOUT; - if (!queue_packet(file, agent, packet)) + if (!queue_packet(file, agent, packet, false)) return; } kfree(packet); @@ -279,7 +286,7 @@ static void recv_handler(struct ib_mad_agent *agent, rdma_destroy_ah_attr(&ah_attr); } - if (queue_packet(file, agent, packet)) + if (queue_packet(file, agent, packet, true)) goto err2; return; @@ -404,6 +411,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, packet = list_entry(file->recv_list.next, struct ib_umad_packet, list); list_del(&packet->list); + atomic_dec(&file->recv_list_size); mutex_unlock(&file->mutex); @@ -416,6 +424,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, /* Requeue packet */ mutex_lock(&file->mutex); list_add(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); mutex_unlock(&file->mutex); } else { if (packet->recv_wc) -- 2.9.5

2 1

[PATCH OLK-5.10] IB/core: Implement a limit on UMAD receive List
by Zhang Changzhong 03 Aug '24

03 Aug '24

From: Michael Guralnik <michaelgur(a)nvidia.com> stable inclusion from stable-v5.10.222 commit 62349fbf86b5e13b02721bdadf98c29afd1e7b5f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGSPA CVE: CVE-2024-42145 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ca0b44e20a6f3032224599f02e7c8fb49525c894 ] The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Signed-off-by: Michael Guralnik <michaelgur(a)nvidia.com> Reviewed-by: Mark Zhang <markzhang(a)nvidia.com> Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.17132688… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/infiniband/core/user_mad.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c index 3bd0dcd..063707d 100644 --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -63,6 +63,8 @@ MODULE_AUTHOR("Roland Dreier"); MODULE_DESCRIPTION("InfiniBand userspace MAD packet access"); MODULE_LICENSE("Dual BSD/GPL"); +#define MAX_UMAD_RECV_LIST_SIZE 200000 + enum { IB_UMAD_MAX_PORTS = RDMA_MAX_PORTS, IB_UMAD_MAX_AGENTS = 32, @@ -113,6 +115,7 @@ struct ib_umad_file { struct mutex mutex; struct ib_umad_port *port; struct list_head recv_list; + atomic_t recv_list_size; struct list_head send_list; struct list_head port_list; spinlock_t send_lock; @@ -180,24 +183,28 @@ static struct ib_mad_agent *__get_agent(struct ib_umad_file *file, int id) return file->agents_dead ? NULL : file->agent[id]; } -static int queue_packet(struct ib_umad_file *file, - struct ib_mad_agent *agent, - struct ib_umad_packet *packet) +static int queue_packet(struct ib_umad_file *file, struct ib_mad_agent *agent, + struct ib_umad_packet *packet, bool is_recv_mad) { int ret = 1; mutex_lock(&file->mutex); + if (is_recv_mad && + atomic_read(&file->recv_list_size) > MAX_UMAD_RECV_LIST_SIZE) + goto unlock; + for (packet->mad.hdr.id = 0; packet->mad.hdr.id < IB_UMAD_MAX_AGENTS; packet->mad.hdr.id++) if (agent == __get_agent(file, packet->mad.hdr.id)) { list_add_tail(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); wake_up_interruptible(&file->recv_wait); ret = 0; break; } - +unlock: mutex_unlock(&file->mutex); return ret; @@ -224,7 +231,7 @@ static void send_handler(struct ib_mad_agent *agent, if (send_wc->status == IB_WC_RESP_TIMEOUT_ERR) { packet->length = IB_MGMT_MAD_HDR; packet->mad.hdr.status = ETIMEDOUT; - if (!queue_packet(file, agent, packet)) + if (!queue_packet(file, agent, packet, false)) return; } kfree(packet); @@ -284,7 +291,7 @@ static void recv_handler(struct ib_mad_agent *agent, rdma_destroy_ah_attr(&ah_attr); } - if (queue_packet(file, agent, packet)) + if (queue_packet(file, agent, packet, true)) goto err2; return; @@ -409,6 +416,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, packet = list_entry(file->recv_list.next, struct ib_umad_packet, list); list_del(&packet->list); + atomic_dec(&file->recv_list_size); mutex_unlock(&file->mutex); @@ -421,6 +429,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, /* Requeue packet */ mutex_lock(&file->mutex); list_add(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); mutex_unlock(&file->mutex); } else { if (packet->recv_wc) -- 2.9.5

2 1

[PATCH openEuler-22.03-LTS-SP1] ppp: reject claimed-as-LCP but actually malformed packets
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v5.10.222 commit 3ba12c2afd933fc1bf800f6d3f6c7ec8f602ce56 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN2 CVE: CVE-2024-41044 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit f2aeb7306a898e1cbd03963d376f4b6656ca2b55 ] Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise. Reported-by: syzbot+ec0723ba9605678b14bf(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ec0723ba9605678b14bf Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ppp/ppp_generic.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index b825c6a9b6dd..e2bca6fa0822 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -70,6 +70,7 @@ #define MPHDRLEN_SSN 4 /* ditto with short sequence numbers */ #define PPP_PROTO_LEN 2 +#define PPP_LCP_HDRLEN 4 /* * An instance of /dev/ppp can be associated with either a ppp @@ -489,6 +490,15 @@ static ssize_t ppp_read(struct file *file, char __user *buf, return ret; } +static bool ppp_check_packet(struct sk_buff *skb, size_t count) +{ + /* LCP packets must include LCP header which 4 bytes long: + * 1-byte code, 1-byte identifier, and 2-byte length. + */ + return get_unaligned_be16(skb->data) != PPP_LCP || + count >= PPP_PROTO_LEN + PPP_LCP_HDRLEN; +} + static ssize_t ppp_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { @@ -511,6 +521,11 @@ static ssize_t ppp_write(struct file *file, const char __user *buf, kfree_skb(skb); goto out; } + ret = -EINVAL; + if (unlikely(!ppp_check_packet(skb, count))) { + kfree_skb(skb); + goto out; + } switch (pf->kind) { case INTERFACE: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] IB/core: Implement a limit on UMAD receive List
by Zhang Changzhong 03 Aug '24

03 Aug '24

From: Michael Guralnik <michaelgur(a)nvidia.com> stable inclusion from stable-v4.19.318 commit 1288cf1cceb0e6df276e182f5412370fb4169bcb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGSPA CVE: CVE-2024-42145 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ca0b44e20a6f3032224599f02e7c8fb49525c894 ] The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Signed-off-by: Michael Guralnik <michaelgur(a)nvidia.com> Reviewed-by: Mark Zhang <markzhang(a)nvidia.com> Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.17132688… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/infiniband/core/user_mad.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c index 4359eda..b37aada 100644 --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -62,6 +62,8 @@ MODULE_AUTHOR("Roland Dreier"); MODULE_DESCRIPTION("InfiniBand userspace MAD packet access"); MODULE_LICENSE("Dual BSD/GPL"); +#define MAX_UMAD_RECV_LIST_SIZE 200000 + enum { IB_UMAD_MAX_PORTS = RDMA_MAX_PORTS, IB_UMAD_MAX_AGENTS = 32, @@ -113,6 +115,7 @@ struct ib_umad_file { struct mutex mutex; struct ib_umad_port *port; struct list_head recv_list; + atomic_t recv_list_size; struct list_head send_list; struct list_head port_list; spinlock_t send_lock; @@ -168,24 +171,28 @@ static struct ib_mad_agent *__get_agent(struct ib_umad_file *file, int id) return file->agents_dead ? NULL : file->agent[id]; } -static int queue_packet(struct ib_umad_file *file, - struct ib_mad_agent *agent, - struct ib_umad_packet *packet) +static int queue_packet(struct ib_umad_file *file, struct ib_mad_agent *agent, + struct ib_umad_packet *packet, bool is_recv_mad) { int ret = 1; mutex_lock(&file->mutex); + if (is_recv_mad && + atomic_read(&file->recv_list_size) > MAX_UMAD_RECV_LIST_SIZE) + goto unlock; + for (packet->mad.hdr.id = 0; packet->mad.hdr.id < IB_UMAD_MAX_AGENTS; packet->mad.hdr.id++) if (agent == __get_agent(file, packet->mad.hdr.id)) { list_add_tail(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); wake_up_interruptible(&file->recv_wait); ret = 0; break; } - +unlock: mutex_unlock(&file->mutex); return ret; @@ -212,7 +219,7 @@ static void send_handler(struct ib_mad_agent *agent, if (send_wc->status == IB_WC_RESP_TIMEOUT_ERR) { packet->length = IB_MGMT_MAD_HDR; packet->mad.hdr.status = ETIMEDOUT; - if (!queue_packet(file, agent, packet)) + if (!queue_packet(file, agent, packet, false)) return; } kfree(packet); @@ -272,7 +279,7 @@ static void recv_handler(struct ib_mad_agent *agent, rdma_destroy_ah_attr(&ah_attr); } - if (queue_packet(file, agent, packet)) + if (queue_packet(file, agent, packet, true)) goto err2; return; @@ -381,6 +388,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, packet = list_entry(file->recv_list.next, struct ib_umad_packet, list); list_del(&packet->list); + atomic_dec(&file->recv_list_size); mutex_unlock(&file->mutex); @@ -393,6 +401,7 @@ static ssize_t ib_umad_read(struct file *filp, char __user *buf, /* Requeue packet */ mutex_lock(&file->mutex); list_add(&packet->list, &file->recv_list); + atomic_inc(&file->recv_list_size); mutex_unlock(&file->mutex); } else { if (packet->recv_wc) -- 2.9.5

2 1

[PATCH OLK-5.10] ppp: reject claimed-as-LCP but actually malformed packets
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v5.10.222 commit 3ba12c2afd933fc1bf800f6d3f6c7ec8f602ce56 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN2 CVE: CVE-2024-41044 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit f2aeb7306a898e1cbd03963d376f4b6656ca2b55 ] Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise. Reported-by: syzbot+ec0723ba9605678b14bf(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ec0723ba9605678b14bf Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ppp/ppp_generic.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index b825c6a9b6dd..e2bca6fa0822 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -70,6 +70,7 @@ #define MPHDRLEN_SSN 4 /* ditto with short sequence numbers */ #define PPP_PROTO_LEN 2 +#define PPP_LCP_HDRLEN 4 /* * An instance of /dev/ppp can be associated with either a ppp @@ -489,6 +490,15 @@ static ssize_t ppp_read(struct file *file, char __user *buf, return ret; } +static bool ppp_check_packet(struct sk_buff *skb, size_t count) +{ + /* LCP packets must include LCP header which 4 bytes long: + * 1-byte code, 1-byte identifier, and 2-byte length. + */ + return get_unaligned_be16(skb->data) != PPP_LCP || + count >= PPP_PROTO_LEN + PPP_LCP_HDRLEN; +} + static ssize_t ppp_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { @@ -511,6 +521,11 @@ static ssize_t ppp_write(struct file *file, const char __user *buf, kfree_skb(skb); goto out; } + ret = -EINVAL; + if (unlikely(!ppp_check_packet(skb, count))) { + kfree_skb(skb); + goto out; + } switch (pf->kind) { case INTERFACE: -- 2.34.1

2 1

[PATCH OLK-6.6] ppp: reject claimed-as-LCP but actually malformed packets
by Liu Jian 03 Aug '24

03 Aug '24

From: Dmitry Antipov <dmantipov(a)yandex.ru> stable inclusion from stable-v6.6.41 commit 099502ca410922b56353ccef2749bc0de669da78 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN2 CVE: CVE-2024-41044 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit f2aeb7306a898e1cbd03963d376f4b6656ca2b55 ] Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise. Reported-by: syzbot+ec0723ba9605678b14bf(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ec0723ba9605678b14bf Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ppp/ppp_generic.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index a9beacd552cf..370c84f39375 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -70,6 +70,7 @@ #define MPHDRLEN_SSN 4 /* ditto with short sequence numbers */ #define PPP_PROTO_LEN 2 +#define PPP_LCP_HDRLEN 4 /* * An instance of /dev/ppp can be associated with either a ppp @@ -491,6 +492,15 @@ static ssize_t ppp_read(struct file *file, char __user *buf, return ret; } +static bool ppp_check_packet(struct sk_buff *skb, size_t count) +{ + /* LCP packets must include LCP header which 4 bytes long: + * 1-byte code, 1-byte identifier, and 2-byte length. + */ + return get_unaligned_be16(skb->data) != PPP_LCP || + count >= PPP_PROTO_LEN + PPP_LCP_HDRLEN; +} + static ssize_t ppp_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { @@ -513,6 +523,11 @@ static ssize_t ppp_write(struct file *file, const char __user *buf, kfree_skb(skb); goto out; } + ret = -EINVAL; + if (unlikely(!ppp_check_packet(skb, count))) { + kfree_skb(skb); + goto out; + } switch (pf->kind) { case INTERFACE: -- 2.34.1

2 1

[PATCH OLK-5.10] drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
by Liu Mingrui 03 Aug '24

03 Aug '24

From: Ma Ke <make24(a)iscas.ac.cn> stable inclusion from stable-v5.10.221 commit 56fc4d3b0bdef691831cd95715a7ca3ebea98b2d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEON CVE: CVE-2024-41089 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream. In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. Cc: stable(a)vger.kernel.org Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> Signed-off-by: Lyude Paul <lyude(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c index be28e7bd7490..f6ecc774193f 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c @@ -257,6 +257,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder, if (modes[i].hdisplay == output_mode->hdisplay && modes[i].vdisplay == output_mode->vdisplay) { mode = drm_mode_duplicate(encoder->dev, output_mode); + if (!mode) + continue; mode->type |= DRM_MODE_TYPE_PREFERRED; } else { @@ -264,6 +266,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder, modes[i].vdisplay, 60, false, (output_mode->flags & DRM_MODE_FLAG_INTERLACE), false); + if (!mode) + continue; } /* CVT modes are sometimes unsuitable... */ -- 2.25.1

2 3

[openeuler:OLK-6.6] BUILD REGRESSION 3cdb76a5e5b7352667ce34bc77526ffbd97de90a
by kernel test robot 03 Aug '24

03 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 3cdb76a5e5b7352667ce34bc77526ffbd97de90a !10545 bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-randconfig-004-20240803 | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-002-20240803 | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- x86_64-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device `-- x86_64-buildonly-randconfig-001-20240803 `-- kernel-sched-isolation.c:error:setup_max_cpus-undeclared-(first-use-in-this-function) elapsed time: 917m configs tested: 24 configs skipped: 117 tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240803 clang-20 arm64 randconfig-002-20240803 clang-20 arm64 randconfig-003-20240803 clang-20 arm64 randconfig-004-20240803 gcc-14.1.0 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240803 gcc-14.1.0 loongarch randconfig-002-20240803 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240803 gcc-12 x86_64 buildonly-randconfig-002-20240803 clang-18 x86_64 buildonly-randconfig-003-20240803 gcc-12 x86_64 buildonly-randconfig-004-20240803 clang-18 x86_64 buildonly-randconfig-005-20240803 clang-18 x86_64 buildonly-randconfig-006-20240803 clang-18 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240803 gcc-12 x86_64 randconfig-002-20240803 gcc-12 x86_64 randconfig-003-20240803 gcc-12 x86_64 randconfig-004-20240803 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
by Liu Mingrui 03 Aug '24

03 Aug '24

From: Ma Ke <make24(a)iscas.ac.cn> stable inclusion from stable-v4.19.317 commit ffabad4aa91e33ced3c6ae793fb37771b3e9cb51 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEON CVE: CVE-2024-41089 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream. In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. Cc: stable(a)vger.kernel.org Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> Signed-off-by: Lyude Paul <lyude(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c index 8fd8124d72ba..3922731361e1 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c @@ -257,6 +257,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder, if (modes[i].hdisplay == output_mode->hdisplay && modes[i].vdisplay == output_mode->vdisplay) { mode = drm_mode_duplicate(encoder->dev, output_mode); + if (!mode) + continue; mode->type |= DRM_MODE_TYPE_PREFERRED; } else { @@ -264,6 +266,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder, modes[i].vdisplay, 60, false, (output_mode->flags & DRM_MODE_FLAG_INTERLACE), false); + if (!mode) + continue; } /* CVT modes are sometimes unsuitable... */ -- 2.25.1

2 1

[PATCH OLK-6.6] net: ethernet: lantiq_etop: fix double free in detach
by Zhengchao Shao 03 Aug '24

03 Aug '24

From: Aleksander Jan Bajkowski <olek2(a)wp.pl> stable inclusion from stable-v6.6.41 commit 9d23909ae041761cb2aa0c3cb1748598d8b6bc54 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKE CVE: CVE-2024-41046 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit e1533b6319ab9c3a97dad314dd88b3783bc41b69 ] The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver") Reported-by: Joe Perches <joe(a)perches.com> Closes: https://lore.kernel.org/all/fc1bf93d92bb5b2f99c6c62745507cc22f3a7b2d.camel@… Signed-off-by: Aleksander Jan Bajkowski <olek2(a)wp.pl> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Link: https://patch.msgid.link/20240708205826.5176-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/lantiq_etop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c index f5961bdcc480..61baf1da76ee 100644 --- a/drivers/net/ethernet/lantiq_etop.c +++ b/drivers/net/ethernet/lantiq_etop.c @@ -217,9 +217,9 @@ ltq_etop_free_channel(struct net_device *dev, struct ltq_etop_chan *ch) if (ch->dma.irq) free_irq(ch->dma.irq, priv); if (IS_RX(ch->idx)) { - int desc; + struct ltq_dma_channel *dma = &ch->dma; - for (desc = 0; desc < LTQ_DESC_NUM; desc++) + for (dma->desc = 0; dma->desc < LTQ_DESC_NUM; dma->desc++) dev_kfree_skb_any(ch->skb[ch->dma.desc]); } } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-41046
by Zhengchao Shao 03 Aug '24

03 Aug '24

Fix CVE-2024-41046. Aleksander Jan Bajkowski (2): net: lantiq_etop: add blank line after declaration net: ethernet: lantiq_etop: fix double free in detach drivers/net/ethernet/lantiq_etop.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] fix CVE-2024-41046
by Zhengchao Shao 03 Aug '24

03 Aug '24

Fix CVE-2024-41046. Aleksander Jan Bajkowski (2): net: lantiq_etop: add blank line after declaration net: ethernet: lantiq_etop: fix double free in detach drivers/net/ethernet/lantiq_etop.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2024-41046
by Zhengchao Shao 03 Aug '24

03 Aug '24

Fix CVE-2024-41046. Aleksander Jan Bajkowski (2): net: lantiq_etop: add blank line after declaration net: ethernet: lantiq_etop: fix double free in detach drivers/net/ethernet/lantiq_etop.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[openeuler:OLK-5.10] BUILD SUCCESS d393777507c56d0caf0bd144d95fc51b95338586
by kernel test robot 03 Aug '24

03 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: d393777507c56d0caf0bd144d95fc51b95338586 !10541 tap: add missing verification for short frame elapsed time: 840m configs tested: 34 configs skipped: 111 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240803 clang-20 arm64 randconfig-002-20240803 clang-20 arm64 randconfig-003-20240803 clang-20 arm64 randconfig-004-20240803 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240803 gcc-12 x86_64 buildonly-randconfig-002-20240803 clang-18 x86_64 buildonly-randconfig-003-20240803 gcc-12 x86_64 buildonly-randconfig-004-20240803 clang-18 x86_64 buildonly-randconfig-005-20240803 clang-18 x86_64 buildonly-randconfig-006-20240803 clang-18 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240803 gcc-12 x86_64 randconfig-002-20240803 gcc-12 x86_64 randconfig-003-20240803 gcc-12 x86_64 randconfig-004-20240803 clang-18 x86_64 randconfig-005-20240803 gcc-12 x86_64 randconfig-006-20240803 gcc-12 x86_64 randconfig-011-20240803 clang-18 x86_64 randconfig-012-20240803 gcc-12 x86_64 randconfig-013-20240803 clang-18 x86_64 randconfig-014-20240803 clang-18 x86_64 randconfig-015-20240803 clang-18 x86_64 randconfig-016-20240803 clang-18 x86_64 randconfig-071-20240803 gcc-12 x86_64 randconfig-072-20240803 gcc-12 x86_64 randconfig-073-20240803 clang-18 x86_64 randconfig-074-20240803 clang-18 x86_64 randconfig-075-20240803 gcc-12 x86_64 randconfig-076-20240803 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS b263c2033617bb9a15cbaa3ee200e1fb75778140
by kernel test robot 03 Aug '24

03 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: b263c2033617bb9a15cbaa3ee200e1fb75778140 !10320 thermal: Fix NULL pointer dereferences in of_thermal_ functions Warning ids grouped by kconfigs: recent_errors |-- x86_64-buildonly-randconfig-003-20240802 | `-- include-asm-generic-atomic-instrumented.h:warning:wait_req-may-be-used-uninitialized |-- x86_64-buildonly-randconfig-004-20240802 | `-- include-asm-generic-atomic-instrumented.h:warning:wait_req-may-be-used-uninitialized |-- x86_64-buildonly-randconfig-005-20240727 | `-- drivers-net-ethernet-hisilicon-hns3-hns3_cae-.tmp_hns3_cae_pfc_storm.o:warning:objtool:missing-symbol-for-section-.text `-- x86_64-buildonly-randconfig-006-20240802 `-- include-asm-generic-atomic-instrumented.h:warning:wait_req-may-be-used-uninitialized elapsed time: 889m configs tested: 32 configs skipped: 101 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240803 gcc-14.1.0 arm64 randconfig-002-20240803 gcc-14.1.0 arm64 randconfig-003-20240803 gcc-14.1.0 arm64 randconfig-004-20240803 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240802 gcc-11 x86_64 buildonly-randconfig-002-20240802 gcc-12 x86_64 buildonly-randconfig-003-20240802 gcc-12 x86_64 buildonly-randconfig-004-20240802 gcc-12 x86_64 buildonly-randconfig-005-20240802 clang-18 x86_64 buildonly-randconfig-006-20240802 gcc-12 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240802 clang-18 x86_64 randconfig-002-20240802 gcc-11 x86_64 randconfig-003-20240802 gcc-12 x86_64 randconfig-004-20240802 gcc-12 x86_64 randconfig-005-20240802 clang-18 x86_64 randconfig-006-20240802 gcc-12 x86_64 randconfig-011-20240802 clang-18 x86_64 randconfig-012-20240802 gcc-12 x86_64 randconfig-013-20240802 gcc-11 x86_64 randconfig-014-20240802 gcc-12 x86_64 randconfig-015-20240802 gcc-12 x86_64 randconfig-016-20240802 clang-18 x86_64 randconfig-071-20240802 gcc-12 x86_64 randconfig-072-20240802 gcc-12 x86_64 randconfig-073-20240802 gcc-12 x86_64 randconfig-074-20240802 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 11566/23411] drivers/net/ethernet/hisilicon/hns3/hns3_cae/.tmp_hns3_cae_pfc_storm.o: warning: objtool: missing symbol for section .text
by kernel test robot 02 Aug '24

02 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: b263c2033617bb9a15cbaa3ee200e1fb75778140 commit: cf7415aa7aae0ef2c815ab271528a29a5ea68c51 [11566/23411] net: hns3: cae module now provides an independent pfc storm cfg feature config: x86_64-buildonly-randconfig-005-20240727 (https://download.01.org/0day-ci/archive/20240802/202408022236.W9r0RrhP-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240802/202408022236.W9r0RrhP-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202408022236.W9r0RrhP-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/.tmp_hns3_cae_pfc_storm.o: warning: objtool: missing symbol for section .text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH] mm: thp: support migration control when numa balancing
by Nanyong Sun 02 Aug '24

02 Aug '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAHJKC CVE: NA -------------------------------- Sometimes migrate THP is not beneficial, for example, when 64K page size is set on ARM64, THP will be 512M, migration may result in performance regression. This featrue add a switch to enalbe THP migration when do numa balancing, default is on, and can disable by: echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate If disabled it, migrate_misplaced_page will return fail and task still have change to migrate. Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 5 +++++ arch/arm64/Kconfig | 1 + include/linux/huge_mm.h | 14 +++++++++++++ mm/Kconfig | 10 ++++++++++ mm/huge_memory.c | 23 ++++++++++++++++++++++ mm/migrate.c | 3 +++ 6 files changed, 56 insertions(+) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2bfb380e8380..97be39a0d5f5 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -160,6 +160,11 @@ library) may want to know the size (in bytes) of a transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size +THP migration can be disabled when do numa balance if +CONFIG_NUMA_MIGRATE_THP_CONTROL is on by:: + + echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate + khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index cae54a9bf65d..b3d0c391a570 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -216,6 +216,7 @@ config ARM64 select SYSCTL_EXCEPTION_TRACE select THREAD_INFO_IN_TASK select HAVE_LIVEPATCH_WO_FTRACE + select NUMA_MIGRATE_THP_CONTROL if ARM64_64K_PAGES help ARM 64-bit (AArch64) Linux support. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index efb370e79ac3..5442889245ef 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -90,6 +90,9 @@ enum transparent_hugepage_flag { #ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG, #endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG, +#endif }; struct kobject; @@ -181,6 +184,14 @@ bool transparent_hugepage_active(struct vm_area_struct *vma); (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG)) +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +#define thp_can_numa_migrate() \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)) +#else +#define thp_can_numa_migrate() 1 +#endif + unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); @@ -485,6 +496,9 @@ static inline bool thp_migration_supported(void) { return false; } + +#define thp_can_numa_migrate() 0 + #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ /** diff --git a/mm/Kconfig b/mm/Kconfig index ccbad233f2b1..311b54078307 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1038,6 +1038,16 @@ config NUMABALANCING_MEM_SAMPLING if unsure, say N to disable the NUMABALANCING_MEM_SAMPLING. +config NUMA_MIGRATE_THP_CONTROL + bool "Control THP migration when numa balancing" + depends on NUMA_BALANCING && TRANSPARENT_HUGEPAGE + default n + help + Sometimes migrate THP is not beneficial, for example, when 64K page + size is set on ARM64, THP will be 512M, migration will be expensive. + This featrue add a switch to control the behavior of THP migration + when do numa balancing. + source "mm/damon/Kconfig" endmenu diff --git a/mm/huge_memory.c b/mm/huge_memory.c index eb293d17a104..c02ffcbad96b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -56,6 +56,9 @@ unsigned long transparent_hugepage_flags __read_mostly = #endif (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG)| (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)| +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)| +#endif (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG); static struct shrinker deferred_split_shrinker; @@ -316,6 +319,23 @@ static ssize_t hpage_pmd_size_show(struct kobject *kobj, static struct kobj_attribute hpage_pmd_size_attr = __ATTR_RO(hpage_pmd_size); +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +static ssize_t numa_migrate_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return single_hugepage_flag_show(kobj, attr, buf, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static ssize_t numa_migrate_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) +{ + return single_hugepage_flag_store(kobj, attr, buf, count, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static struct kobj_attribute numa_migrate_attr = + __ATTR(numa_migrate, 0644, numa_migrate_show, numa_migrate_store); +#endif + static struct attribute *hugepage_attr[] = { &enabled_attr.attr, &defrag_attr.attr, @@ -323,6 +343,9 @@ static struct attribute *hugepage_attr[] = { &hpage_pmd_size_attr.attr, #ifdef CONFIG_SHMEM &shmem_enabled_attr.attr, +#endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + &numa_migrate_attr.attr, #endif NULL, }; diff --git a/mm/migrate.c b/mm/migrate.c index 3f5b217d5af1..f7eb9b4c8668 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2157,6 +2157,9 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma, */ compound = PageTransHuge(page); + if (compound && !thp_can_numa_migrate()) + return 0; + if (compound) new = alloc_misplaced_dst_page_thp; else -- 2.25.1

1 0

[PATCH openEuler-22.03-LTS-SP1 0/4] fix CVE-2024-41062
by Zhengchao Shao 02 Aug '24

02 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (2): Bluetooth: L2CAP: Fix deadlock Bluetooth: Fix usage of __hci_cmd_sync_status Marcel Holtmann (1): Bluetooth: Add helper for serialized HCI command execution include/net/bluetooth/hci_core.h | 11 +- include/net/bluetooth/hci_sync.h | 44 ++++ net/bluetooth/Makefile | 2 +- net/bluetooth/hci_core.c | 92 ++------- net/bluetooth/hci_request.c | 68 ------ net/bluetooth/hci_request.h | 4 + net/bluetooth/hci_sync.c | 343 +++++++++++++++++++++++++++++++ net/bluetooth/l2cap_core.c | 3 + net/bluetooth/l2cap_sock.c | 10 +- 9 files changed, 427 insertions(+), 150 deletions(-) create mode 100644 include/net/bluetooth/hci_sync.h create mode 100644 net/bluetooth/hci_sync.c -- 2.34.1

2 5

[PATCH OLK-5.10 0/4] fix CVE-2024-41062
by Zhengchao Shao 02 Aug '24

02 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (2): Bluetooth: L2CAP: Fix deadlock Bluetooth: Fix usage of __hci_cmd_sync_status Marcel Holtmann (1): Bluetooth: Add helper for serialized HCI command execution include/net/bluetooth/hci_core.h | 11 +- include/net/bluetooth/hci_sync.h | 44 ++++ net/bluetooth/Makefile | 2 +- net/bluetooth/hci_core.c | 92 ++------- net/bluetooth/hci_request.c | 68 ------ net/bluetooth/hci_request.h | 4 + net/bluetooth/hci_sync.c | 343 +++++++++++++++++++++++++++++++ net/bluetooth/l2cap_core.c | 3 + net/bluetooth/l2cap_sock.c | 10 +- 9 files changed, 427 insertions(+), 150 deletions(-) create mode 100644 include/net/bluetooth/hci_sync.h create mode 100644 net/bluetooth/hci_sync.c -- 2.34.1

2 5

[PATCH OLK-5.10] mm: thp: support migration control when numa balancing
by Nanyong Sun 02 Aug '24

02 Aug '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAHJKC CVE: NA -------------------------------- Sometimes migrate THP is not beneficial, for example, when 64K page size is set on ARM64, THP will be 512M, migration may result in performance regression. This featrue add a switch to enalbe THP migration when do numa balancing, default is on, and can disable by: echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate If disabled it, migrate_misplaced_page will return fail and task still have change to migrate. Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 5 +++++ arch/arm64/Kconfig | 1 + include/linux/huge_mm.h | 14 +++++++++++++ mm/Kconfig | 10 ++++++++++ mm/huge_memory.c | 23 ++++++++++++++++++++++ mm/migrate.c | 3 +++ 6 files changed, 56 insertions(+) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2bfb380e8380..97be39a0d5f5 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -160,6 +160,11 @@ library) may want to know the size (in bytes) of a transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size +THP migration can be disabled when do numa balance if +CONFIG_NUMA_MIGRATE_THP_CONTROL is on by:: + + echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate + khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index cae54a9bf65d..b3d0c391a570 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -216,6 +216,7 @@ config ARM64 select SYSCTL_EXCEPTION_TRACE select THREAD_INFO_IN_TASK select HAVE_LIVEPATCH_WO_FTRACE + select NUMA_MIGRATE_THP_CONTROL if ARM64_64K_PAGES help ARM 64-bit (AArch64) Linux support. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index efb370e79ac3..5442889245ef 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -90,6 +90,9 @@ enum transparent_hugepage_flag { #ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG, #endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG, +#endif }; struct kobject; @@ -181,6 +184,14 @@ bool transparent_hugepage_active(struct vm_area_struct *vma); (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG)) +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +#define thp_can_numa_migrate() \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)) +#else +#define thp_can_numa_migrate() 1 +#endif + unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); @@ -485,6 +496,9 @@ static inline bool thp_migration_supported(void) { return false; } + +#define thp_can_numa_migrate() 0 + #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ /** diff --git a/mm/Kconfig b/mm/Kconfig index ccbad233f2b1..311b54078307 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1038,6 +1038,16 @@ config NUMABALANCING_MEM_SAMPLING if unsure, say N to disable the NUMABALANCING_MEM_SAMPLING. +config NUMA_MIGRATE_THP_CONTROL + bool "Control THP migration when numa balancing" + depends on NUMA_BALANCING && TRANSPARENT_HUGEPAGE + default n + help + Sometimes migrate THP is not beneficial, for example, when 64K page + size is set on ARM64, THP will be 512M, migration will be expensive. + This featrue add a switch to control the behavior of THP migration + when do numa balancing. + source "mm/damon/Kconfig" endmenu diff --git a/mm/huge_memory.c b/mm/huge_memory.c index eb293d17a104..c02ffcbad96b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -56,6 +56,9 @@ unsigned long transparent_hugepage_flags __read_mostly = #endif (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG)| (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)| +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)| +#endif (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG); static struct shrinker deferred_split_shrinker; @@ -316,6 +319,23 @@ static ssize_t hpage_pmd_size_show(struct kobject *kobj, static struct kobj_attribute hpage_pmd_size_attr = __ATTR_RO(hpage_pmd_size); +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +static ssize_t numa_migrate_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return single_hugepage_flag_show(kobj, attr, buf, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static ssize_t numa_migrate_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) +{ + return single_hugepage_flag_store(kobj, attr, buf, count, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static struct kobj_attribute numa_migrate_attr = + __ATTR(numa_migrate, 0644, numa_migrate_show, numa_migrate_store); +#endif + static struct attribute *hugepage_attr[] = { &enabled_attr.attr, &defrag_attr.attr, @@ -323,6 +343,9 @@ static struct attribute *hugepage_attr[] = { &hpage_pmd_size_attr.attr, #ifdef CONFIG_SHMEM &shmem_enabled_attr.attr, +#endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + &numa_migrate_attr.attr, #endif NULL, }; diff --git a/mm/migrate.c b/mm/migrate.c index 3f5b217d5af1..f7eb9b4c8668 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2157,6 +2157,9 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma, */ compound = PageTransHuge(page); + if (compound && !thp_can_numa_migrate()) + return 0; + if (compound) new = alloc_misplaced_dst_page_thp; else -- 2.25.1

2 1

[PATCH OLK-5.10 v2] ax25: Fix refcount imbalance on inbound connections
by Dong Chenchen 02 Aug '24

02 Aug '24

From: Lars Kellogg-Stedman <lars(a)oddbit.com> mainline inclusion from mainline-v6.10-rc3 commit 3c34fb0bd4a4237592c5ecb5b2e2531900c55774 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYN CVE: CVE-2024-40910 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Lars Kellogg-Stedman <lars(a)oddbit.com> Tested-by: Duoming Zhou <duoming(a)zju.edu.cn> Tested-by: Dan Cross <crossd(a)gmail.com> Tested-by: Chris Maness <christopher.maness(a)gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20240529210242.3346844-2-lars@oddbit.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/af_ax25.c [commit d62607c3fe45 add netdev_hold() to track refcnt, which not merged lead to conflicts. We can use dev_hold().] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ax25/af_ax25.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index a1f4cb836fcf..8d45ca82bd7d 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -1369,8 +1369,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, { struct sk_buff *skb; struct sock *newsk; + ax25_dev *ax25_dev; DEFINE_WAIT(wait); struct sock *sk; + ax25_cb *ax25; int err = 0; if (sock->state != SS_UNCONNECTED) @@ -1425,6 +1427,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, kfree_skb(skb); sk_acceptq_removed(sk); newsock->state = SS_CONNECTED; + ax25 = sk_to_ax25(newsk); + ax25_dev = ax25->ax25_dev; + dev_hold(ax25_dev->dev); + ax25_dev_hold(ax25_dev); out: release_sock(sk); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 v2] ax25: Fix refcount imbalance on inbound connections
by Dong Chenchen 02 Aug '24

02 Aug '24

From: Lars Kellogg-Stedman <lars(a)oddbit.com> mainline inclusion from mainline-v6.10-rc3 commit 3c34fb0bd4a4237592c5ecb5b2e2531900c55774 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYN CVE: CVE-2024-40910 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Lars Kellogg-Stedman <lars(a)oddbit.com> Tested-by: Duoming Zhou <duoming(a)zju.edu.cn> Tested-by: Dan Cross <crossd(a)gmail.com> Tested-by: Chris Maness <christopher.maness(a)gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20240529210242.3346844-2-lars@oddbit.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/af_ax25.c [commit d62607c3fe45 add netdev_hold() to track refcnt, which not merged lead to conflicts. We can use dev_hold().] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ax25/af_ax25.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index a1f4cb836fcf..8d45ca82bd7d 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -1369,8 +1369,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, { struct sk_buff *skb; struct sock *newsk; + ax25_dev *ax25_dev; DEFINE_WAIT(wait); struct sock *sk; + ax25_cb *ax25; int err = 0; if (sock->state != SS_UNCONNECTED) @@ -1425,6 +1427,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, kfree_skb(skb); sk_acceptq_removed(sk); newsock->state = SS_CONNECTED; + ax25 = sk_to_ax25(newsk); + ax25_dev = ax25->ax25_dev; + dev_hold(ax25_dev->dev); + ax25_dev_hold(ax25_dev); out: release_sock(sk); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 02 Aug '24

02 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 6e118955b9b6..6280fbb613de 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2661,8 +2661,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2676,9 +2677,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-5.10] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 02 Aug '24

02 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index f4504008a2ea..6f27ec4f58da 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2661,8 +2661,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2676,9 +2677,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by y00878127 02 Aug '24

02 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): clean code drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 3 ++- virt/kvm/vfio.c | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 02 Aug '24

02 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): clean code drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 3 ++- virt/kvm/vfio.c | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1] ax25: Fix refcount imbalance on inbound connections
by Dong Chenchen 02 Aug '24

02 Aug '24

From: Lars Kellogg-Stedman <lars(a)oddbit.com> mainline inclusion from mainline-v6.10-rc3 commit 3c34fb0bd4a4237592c5ecb5b2e2531900c55774 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYN CVE: CVE-2024-40910 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Lars Kellogg-Stedman <lars(a)oddbit.com> Tested-by: Duoming Zhou <duoming(a)zju.edu.cn> Tested-by: Dan Cross <crossd(a)gmail.com> Tested-by: Chris Maness <christopher.maness(a)gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20240529210242.3346844-2-lars@oddbit.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ax25/af_ax25.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index a1f4cb836fcf..e30414e991c3 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -1369,8 +1369,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, { struct sk_buff *skb; struct sock *newsk; + ax25_dev *ax25_dev; DEFINE_WAIT(wait); struct sock *sk; + ax25_cb *ax25; int err = 0; if (sock->state != SS_UNCONNECTED) @@ -1425,6 +1427,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, kfree_skb(skb); sk_acceptq_removed(sk); newsock->state = SS_CONNECTED; + ax25 = sk_to_ax25(newsk); + ax25_dev = ax25->ax25_dev; + netdev_hold(ax25_dev->dev, &ax25->dev_tracker, GFP_ATOMIC); + ax25_dev_hold(ax25_dev); out: release_sock(sk); -- 2.25.1

2 1