- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] net: dsa: mv88e6xxx: Correct check for empty list
by Liu Jian 03 Aug '24

03 Aug '24

From: Simon Horman <horms(a)kernel.org> stable inclusion from stable-v4.19.318 commit 47d28dde172696031c880c5778633cdca30394ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGSOT CVE: CVE-2024-42224 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b ] Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only. Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Simon Horman <horms(a)kernel.org> Link: https://lore.kernel.org/r/20240430-mv88e6xx-list_empty-v3-1-c35c69d88d2e@ke… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/dsa/mv88e6xxx/chip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 43b00e8bcdcd..93c893731acb 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -231,8 +231,8 @@ struct mii_bus *mv88e6xxx_default_mdio_bus(struct mv88e6xxx_chip *chip) { struct mv88e6xxx_mdio_bus *mdio_bus; - mdio_bus = list_first_entry(&chip->mdios, struct mv88e6xxx_mdio_bus, - list); + mdio_bus = list_first_entry_or_null(&chip->mdios, + struct mv88e6xxx_mdio_bus, list); if (!mdio_bus) return NULL; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] inet_diag: Initialize pad field in struct inet_diag_req_v2
by Zhengchao Shao 03 Aug '24

03 Aug '24

From: Shigeru Yoshida <syoshida(a)redhat.com> stable inclusion from stable-v5.10.222 commit 7ef519c8efde152e0d632337f2994f6921e0b7e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGPRU CVE: CVE-2024-42106 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 61cf1c739f08190a4cbf047b9fbb192a94d87e3f ] KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20240703091649.111773-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv4/inet_diag.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c index fa9f1de58df4..87209a7fb28c 100644 --- a/net/ipv4/inet_diag.c +++ b/net/ipv4/inet_diag.c @@ -1275,6 +1275,7 @@ static int inet_diag_dump_compat(struct sk_buff *skb, req.sdiag_family = AF_UNSPEC; /* compatibility */ req.sdiag_protocol = inet_diag_type2proto(cb->nlh->nlmsg_type); req.idiag_ext = rc->idiag_ext; + req.pad = 0; req.idiag_states = rc->idiag_states; req.id = rc->id; @@ -1290,6 +1291,7 @@ static int inet_diag_get_exact_compat(struct sk_buff *in_skb, req.sdiag_family = rc->idiag_family; req.sdiag_protocol = inet_diag_type2proto(nlh->nlmsg_type); req.idiag_ext = rc->idiag_ext; + req.pad = 0; req.idiag_states = rc->idiag_states; req.id = rc->id; -- 2.34.1

2 1

[PATCH OLK-5.10] inet_diag: Initialize pad field in struct inet_diag_req_v2
by Zhengchao Shao 03 Aug '24

03 Aug '24

From: Shigeru Yoshida <syoshida(a)redhat.com> stable inclusion from stable-v5.10.222 commit 7ef519c8efde152e0d632337f2994f6921e0b7e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGPRU CVE: CVE-2024-42106 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 61cf1c739f08190a4cbf047b9fbb192a94d87e3f ] KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20240703091649.111773-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv4/inet_diag.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c index fa9f1de58df4..87209a7fb28c 100644 --- a/net/ipv4/inet_diag.c +++ b/net/ipv4/inet_diag.c @@ -1275,6 +1275,7 @@ static int inet_diag_dump_compat(struct sk_buff *skb, req.sdiag_family = AF_UNSPEC; /* compatibility */ req.sdiag_protocol = inet_diag_type2proto(cb->nlh->nlmsg_type); req.idiag_ext = rc->idiag_ext; + req.pad = 0; req.idiag_states = rc->idiag_states; req.id = rc->id; @@ -1290,6 +1291,7 @@ static int inet_diag_get_exact_compat(struct sk_buff *in_skb, req.sdiag_family = rc->idiag_family; req.sdiag_protocol = inet_diag_type2proto(nlh->nlmsg_type); req.idiag_ext = rc->idiag_ext; + req.pad = 0; req.idiag_states = rc->idiag_states; req.id = rc->id; -- 2.34.1

2 1

[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> stable inclusion from stable-v4.19.318 commit d8418fd083d1b90a6c007cf8dcf81aeae274727b 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> 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 OLK-5.10] usb: atm: cxacru: fix endpoint checking in cxacru_bind()
by Luo Gengkun 03 Aug '24

03 Aug '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc6 commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOL CVE: CVE-2024-41097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 Reported-and-tested-by: syzbot+00c18ee8497dd3be6ade(a)syzkaller.appspotmail.com Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint") Cc: stable <stable(a)kernel.org> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240609131546.3932-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/usb/atm/cxacru.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c index e62a770a5d3b..1d2c736dbf6a 100644 --- a/drivers/usb/atm/cxacru.c +++ b/drivers/usb/atm/cxacru.c @@ -1134,6 +1134,7 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, struct cxacru_data *instance; struct usb_device *usb_dev = interface_to_usbdev(intf); struct usb_host_endpoint *cmd_ep = usb_dev->ep_in[CXACRU_EP_CMD]; + struct usb_endpoint_descriptor *in, *out; int ret; /* instance init */ @@ -1180,6 +1181,19 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, goto fail; } + if (usb_endpoint_xfer_int(&cmd_ep->desc)) + ret = usb_find_common_endpoints(intf->cur_altsetting, + NULL, NULL, &in, &out); + else + ret = usb_find_common_endpoints(intf->cur_altsetting, + &in, &out, NULL, NULL); + + if (ret) { + usb_err(usbatm_instance, "cxacru_bind: interface has incorrect endpoints\n"); + ret = -ENODEV; + goto fail; + } + if ((cmd_ep->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { usb_fill_int_urb(instance->rcv_urb, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] usb: atm: cxacru: fix endpoint checking in cxacru_bind()
by Luo Gengkun 03 Aug '24

03 Aug '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc6 commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOL CVE: CVE-2024-41097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 Reported-and-tested-by: syzbot+00c18ee8497dd3be6ade(a)syzkaller.appspotmail.com Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint") Cc: stable <stable(a)kernel.org> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240609131546.3932-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/usb/atm/cxacru.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c index e62a770a5d3b..1d2c736dbf6a 100644 --- a/drivers/usb/atm/cxacru.c +++ b/drivers/usb/atm/cxacru.c @@ -1134,6 +1134,7 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, struct cxacru_data *instance; struct usb_device *usb_dev = interface_to_usbdev(intf); struct usb_host_endpoint *cmd_ep = usb_dev->ep_in[CXACRU_EP_CMD]; + struct usb_endpoint_descriptor *in, *out; int ret; /* instance init */ @@ -1180,6 +1181,19 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, goto fail; } + if (usb_endpoint_xfer_int(&cmd_ep->desc)) + ret = usb_find_common_endpoints(intf->cur_altsetting, + NULL, NULL, &in, &out); + else + ret = usb_find_common_endpoints(intf->cur_altsetting, + &in, &out, NULL, NULL); + + if (ret) { + usb_err(usbatm_instance, "cxacru_bind: interface has incorrect endpoints\n"); + ret = -ENODEV; + goto fail; + } + if ((cmd_ep->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { usb_fill_int_urb(instance->rcv_urb, -- 2.34.1

2 1

[PATCH OLK-6.6] gve: Account for stopped queues when reading NIC stats
by Zhang Changzhong 03 Aug '24

03 Aug '24

From: Shailend Chand <shailend(a)google.com> mainline inclusion from mainline-v6.10-rc1 commit af9bcf910b1f86244f39e15e701b2dc564b469a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGRY7 CVE: CVE-2024-42162 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gve_get_ethtool_stats might make an invalid access on the priv->stats_report->stats array. Tested-by: Mina Almasry <almasrymina(a)google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi(a)google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy(a)google.com> Signed-off-by: Shailend Chand <shailend(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: drivers/net/ethernet/google/gve/gve_ethtool.c [commit 056a70924a02 ("gve: Add header split ethtool stats") is not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/ethernet/google/gve/gve_ethtool.c | 41 +++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c b/drivers/net/ethernet/google/gve/gve_ethtool.c index 233e594..38e646f 100644 --- a/drivers/net/ethernet/google/gve/gve_ethtool.c +++ b/drivers/net/ethernet/google/gve/gve_ethtool.c @@ -9,6 +9,7 @@ #include "gve.h" #include "gve_adminq.h" #include "gve_dqo.h" +#include "gve_utils.h" static void gve_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *info) @@ -163,6 +164,8 @@ gve_get_ethtool_stats(struct net_device *netdev, struct stats *report_stats; int *rx_qid_to_stats_idx; int *tx_qid_to_stats_idx; + int num_stopped_rxqs = 0; + int num_stopped_txqs = 0; struct gve_priv *priv; bool skip_nic_stats; unsigned int start; @@ -179,12 +182,23 @@ gve_get_ethtool_stats(struct net_device *netdev, sizeof(int), GFP_KERNEL); if (!rx_qid_to_stats_idx) return; + for (ring = 0; ring < priv->rx_cfg.num_queues; ring++) { + rx_qid_to_stats_idx[ring] = -1; + if (!gve_rx_was_added_to_block(priv, ring)) + num_stopped_rxqs++; + } tx_qid_to_stats_idx = kmalloc_array(num_tx_queues, sizeof(int), GFP_KERNEL); if (!tx_qid_to_stats_idx) { kfree(rx_qid_to_stats_idx); return; } + for (ring = 0; ring < num_tx_queues; ring++) { + tx_qid_to_stats_idx[ring] = -1; + if (!gve_tx_was_added_to_block(priv, ring)) + num_stopped_txqs++; + } + for (rx_pkts = 0, rx_bytes = 0, rx_skb_alloc_fail = 0, rx_buf_alloc_fail = 0, rx_desc_err_dropped_pkt = 0, ring = 0; ring < priv->rx_cfg.num_queues; ring++) { @@ -249,7 +263,13 @@ gve_get_ethtool_stats(struct net_device *netdev, /* For rx cross-reporting stats, start from nic rx stats in report */ base_stats_idx = GVE_TX_STATS_REPORT_NUM * num_tx_queues + GVE_RX_STATS_REPORT_NUM * priv->rx_cfg.num_queues; - max_stats_idx = NIC_RX_STATS_REPORT_NUM * priv->rx_cfg.num_queues + + /* The boundary between driver stats and NIC stats shifts if there are + * stopped queues. + */ + base_stats_idx += NIC_RX_STATS_REPORT_NUM * num_stopped_rxqs + + NIC_TX_STATS_REPORT_NUM * num_stopped_txqs; + max_stats_idx = NIC_RX_STATS_REPORT_NUM * + (priv->rx_cfg.num_queues - num_stopped_rxqs) + base_stats_idx; /* Preprocess the stats report for rx, map queue id to start index */ skip_nic_stats = false; @@ -263,6 +283,10 @@ gve_get_ethtool_stats(struct net_device *netdev, skip_nic_stats = true; break; } + if (queue_id < 0 || queue_id >= priv->rx_cfg.num_queues) { + net_err_ratelimited("Invalid rxq id in NIC stats\n"); + continue; + } rx_qid_to_stats_idx[queue_id] = stats_idx; } /* walk RX rings */ @@ -295,11 +319,11 @@ gve_get_ethtool_stats(struct net_device *netdev, data[i++] = rx->rx_copybreak_pkt; data[i++] = rx->rx_copied_pkt; /* stats from NIC */ - if (skip_nic_stats) { + stats_idx = rx_qid_to_stats_idx[ring]; + if (skip_nic_stats || stats_idx < 0) { /* skip NIC rx stats */ i += NIC_RX_STATS_REPORT_NUM; } else { - stats_idx = rx_qid_to_stats_idx[ring]; for (j = 0; j < NIC_RX_STATS_REPORT_NUM; j++) { u64 value = be64_to_cpu(report_stats[stats_idx + j].value); @@ -325,7 +349,8 @@ gve_get_ethtool_stats(struct net_device *netdev, /* For tx cross-reporting stats, start from nic tx stats in report */ base_stats_idx = max_stats_idx; - max_stats_idx = NIC_TX_STATS_REPORT_NUM * num_tx_queues + + max_stats_idx = NIC_TX_STATS_REPORT_NUM * + (num_tx_queues - num_stopped_txqs) + max_stats_idx; /* Preprocess the stats report for tx, map queue id to start index */ skip_nic_stats = false; @@ -339,6 +364,10 @@ gve_get_ethtool_stats(struct net_device *netdev, skip_nic_stats = true; break; } + if (queue_id < 0 || queue_id >= num_tx_queues) { + net_err_ratelimited("Invalid txq id in NIC stats\n"); + continue; + } tx_qid_to_stats_idx[queue_id] = stats_idx; } /* walk TX rings */ @@ -370,11 +399,11 @@ gve_get_ethtool_stats(struct net_device *netdev, data[i++] = gve_tx_load_event_counter(priv, tx); data[i++] = tx->dma_mapping_error; /* stats from NIC */ - if (skip_nic_stats) { + stats_idx = tx_qid_to_stats_idx[ring]; + if (skip_nic_stats || stats_idx < 0) { /* skip NIC tx stats */ i += NIC_TX_STATS_REPORT_NUM; } else { - stats_idx = tx_qid_to_stats_idx[ring]; for (j = 0; j < NIC_TX_STATS_REPORT_NUM; j++) { u64 value = be64_to_cpu(report_stats[stats_idx + j].value); -- 2.9.5

2 1

[PATCH OLK-6.6] s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception()
by Huang Xiaojia 03 Aug '24

03 Aug '24

From: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> mainline inclusion from mainline-v6.11-rc1 commit df39038cd89525d465c2c8827eb64116873f141a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF2 CVE: CVE-2024-41021 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on s390. Therefore we do not expect to see VM_FAULT_HWPOISON in do_exception(). However, since commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general"), it is possible to see VM_FAULT_HWPOISON in combination with PTE_MARKER_POISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in do_exception(). Fix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging. Note that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level. Cc: stable(a)vger.kernel.org # 6.6+ Fixes: af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general") Reported-by: Yunseong Kim <yskelg(a)gmail.com> Tested-by: Yunseong Kim <yskelg(a)gmail.com> Acked-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Message-ID: <20240715180416.3632453-1-gerald.schaefer(a)linux.ibm.com> Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com> Conflicts: arch/s390/mm/fault.c [huangxiaojia adapt context conflicts.] Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/s390/mm/fault.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c index f5463535013a..0f3ce563056f 100644 --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -331,14 +331,16 @@ static noinline void do_fault_error(struct pt_regs *regs, vm_fault_t fault) do_no_context(regs, fault); else do_sigsegv(regs, SEGV_MAPERR); - } else if (fault & VM_FAULT_SIGBUS) { + } else if (fault & (VM_FAULT_SIGBUS | VM_FAULT_HWPOISON)) { /* Kernel mode? Handle exceptions or die */ if (!user_mode(regs)) do_no_context(regs, fault); else do_sigbus(regs); - } else + } else { + pr_emerg("Unexpected fault flags: %08x\n", fault); BUG(); + } break; } } -- 2.34.1

2 1

[PATCH] s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception()
by Huang Xiaojia 03 Aug '24

03 Aug '24

From: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> mainline inclusion from mainline-v6.11-rc1 commit df39038cd89525d465c2c8827eb64116873f141a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF2 CVE: CVE-2024-41021 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on s390. Therefore we do not expect to see VM_FAULT_HWPOISON in do_exception(). However, since commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general"), it is possible to see VM_FAULT_HWPOISON in combination with PTE_MARKER_POISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in do_exception(). Fix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging. Note that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level. Cc: stable(a)vger.kernel.org # 6.6+ Fixes: af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general") Reported-by: Yunseong Kim <yskelg(a)gmail.com> Tested-by: Yunseong Kim <yskelg(a)gmail.com> Acked-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Message-ID: <20240715180416.3632453-1-gerald.schaefer(a)linux.ibm.com> Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com> Conflicts: arch/s390/mm/fault.c [huangxiaojia adapt context conflicts.] Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/s390/mm/fault.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c index f5463535013a..0f3ce563056f 100644 --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -331,14 +331,16 @@ static noinline void do_fault_error(struct pt_regs *regs, vm_fault_t fault) do_no_context(regs, fault); else do_sigsegv(regs, SEGV_MAPERR); - } else if (fault & VM_FAULT_SIGBUS) { + } else if (fault & (VM_FAULT_SIGBUS | VM_FAULT_HWPOISON)) { /* Kernel mode? Handle exceptions or die */ if (!user_mode(regs)) do_no_context(regs, fault); else do_sigbus(regs); - } else + } else { + pr_emerg("Unexpected fault flags: %08x\n", fault); BUG(); + } break; } } -- 2.34.1

1 0

[PATCH openEuler-22.03-LTS-SP1] usb: atm: cxacru: fix endpoint checking in cxacru_bind()
by Luo Gengkun 03 Aug '24

03 Aug '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc6 commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOL CVE: CVE-2024-41097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 Reported-and-tested-by: syzbot+00c18ee8497dd3be6ade(a)syzkaller.appspotmail.com Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint") Cc: stable <stable(a)kernel.org> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240609131546.3932-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/usb/atm/cxacru.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c index e62a770a5d3b..1d2c736dbf6a 100644 --- a/drivers/usb/atm/cxacru.c +++ b/drivers/usb/atm/cxacru.c @@ -1134,6 +1134,7 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, struct cxacru_data *instance; struct usb_device *usb_dev = interface_to_usbdev(intf); struct usb_host_endpoint *cmd_ep = usb_dev->ep_in[CXACRU_EP_CMD]; + struct usb_endpoint_descriptor *in, *out; int ret; /* instance init */ @@ -1180,6 +1181,19 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, goto fail; } + if (usb_endpoint_xfer_int(&cmd_ep->desc)) + ret = usb_find_common_endpoints(intf->cur_altsetting, + NULL, NULL, &in, &out); + else + ret = usb_find_common_endpoints(intf->cur_altsetting, + &in, &out, NULL, NULL); + + if (ret) { + usb_err(usbatm_instance, "cxacru_bind: interface has incorrect endpoints\n"); + ret = -ENODEV; + goto fail; + } + if ((cmd_ep->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { usb_fill_int_urb(instance->rcv_urb, -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] RDMA/restrack: Fix potential invalid address access
by Zhengchao Shao 03 Aug '24

03 Aug '24

From: Wenchao Hao <haowenchao2(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit ca537a34775c103f7b14d7bbd976403f1d1525d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOR CVE: CVE-2024-42080 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them. Signed-off-by: Wenchao Hao <haowenchao2(a)huawei.com> Link: https://lore.kernel.org/r/20240318092320.1215235-1-haowenchao2@huawei.com Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/core/restrack.c [The conflict occurs because the commit 48f8a70e899f("RDMA/restrack: Add support to get resource tracking for SRQ") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/core/restrack.c | 50 +----------------------------- 1 file changed, 1 insertion(+), 49 deletions(-) diff --git a/drivers/infiniband/core/restrack.c b/drivers/infiniband/core/restrack.c index bbbbec5b1593..ea6ce7662456 100644 --- a/drivers/infiniband/core/restrack.c +++ b/drivers/infiniband/core/restrack.c @@ -37,21 +37,6 @@ int rdma_restrack_init(struct ib_device *dev) return 0; } -static const char *type2str(enum rdma_restrack_type type) -{ - static const char * const names[RDMA_RESTRACK_MAX] = { - [RDMA_RESTRACK_PD] = "PD", - [RDMA_RESTRACK_CQ] = "CQ", - [RDMA_RESTRACK_QP] = "QP", - [RDMA_RESTRACK_CM_ID] = "CM_ID", - [RDMA_RESTRACK_MR] = "MR", - [RDMA_RESTRACK_CTX] = "CTX", - [RDMA_RESTRACK_COUNTER] = "COUNTER", - }; - - return names[type]; -}; - /** * rdma_restrack_clean() - clean resource tracking * @dev: IB device @@ -59,47 +44,14 @@ static const char *type2str(enum rdma_restrack_type type) void rdma_restrack_clean(struct ib_device *dev) { struct rdma_restrack_root *rt = dev->res; - struct rdma_restrack_entry *e; - char buf[TASK_COMM_LEN]; - bool found = false; - const char *owner; int i; for (i = 0 ; i < RDMA_RESTRACK_MAX; i++) { struct xarray *xa = &dev->res[i].xa; - if (!xa_empty(xa)) { - unsigned long index; - - if (!found) { - pr_err("restrack: %s", CUT_HERE); - dev_err(&dev->dev, "BUG: RESTRACK detected leak of resources\n"); - } - xa_for_each(xa, index, e) { - if (rdma_is_kernel_res(e)) { - owner = e->kern_name; - } else { - /* - * There is no need to call get_task_struct here, - * because we can be here only if there are more - * get_task_struct() call than put_task_struct(). - */ - get_task_comm(buf, e->task); - owner = buf; - } - - pr_err("restrack: %s %s object allocated by %s is not freed\n", - rdma_is_kernel_res(e) ? "Kernel" : - "User", - type2str(e->type), owner); - } - found = true; - } + WARN_ON(!xa_empty(xa)); xa_destroy(xa); } - if (found) - pr_err("restrack: %s", CUT_HERE); - kfree(rt); } -- 2.34.1

2 1

[PATCH OLK-5.10] RDMA/restrack: Fix potential invalid address access
by Zhengchao Shao 03 Aug '24

03 Aug '24

From: Wenchao Hao <haowenchao2(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit ca537a34775c103f7b14d7bbd976403f1d1525d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOR CVE: CVE-2024-42080 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them. Signed-off-by: Wenchao Hao <haowenchao2(a)huawei.com> Link: https://lore.kernel.org/r/20240318092320.1215235-1-haowenchao2@huawei.com Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/core/restrack.c [The conflict occurs because the commit 48f8a70e899f("RDMA/restrack: Add support to get resource tracking for SRQ") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/core/restrack.c | 50 +----------------------------- 1 file changed, 1 insertion(+), 49 deletions(-) diff --git a/drivers/infiniband/core/restrack.c b/drivers/infiniband/core/restrack.c index bbbbec5b1593..ea6ce7662456 100644 --- a/drivers/infiniband/core/restrack.c +++ b/drivers/infiniband/core/restrack.c @@ -37,21 +37,6 @@ int rdma_restrack_init(struct ib_device *dev) return 0; } -static const char *type2str(enum rdma_restrack_type type) -{ - static const char * const names[RDMA_RESTRACK_MAX] = { - [RDMA_RESTRACK_PD] = "PD", - [RDMA_RESTRACK_CQ] = "CQ", - [RDMA_RESTRACK_QP] = "QP", - [RDMA_RESTRACK_CM_ID] = "CM_ID", - [RDMA_RESTRACK_MR] = "MR", - [RDMA_RESTRACK_CTX] = "CTX", - [RDMA_RESTRACK_COUNTER] = "COUNTER", - }; - - return names[type]; -}; - /** * rdma_restrack_clean() - clean resource tracking * @dev: IB device @@ -59,47 +44,14 @@ static const char *type2str(enum rdma_restrack_type type) void rdma_restrack_clean(struct ib_device *dev) { struct rdma_restrack_root *rt = dev->res; - struct rdma_restrack_entry *e; - char buf[TASK_COMM_LEN]; - bool found = false; - const char *owner; int i; for (i = 0 ; i < RDMA_RESTRACK_MAX; i++) { struct xarray *xa = &dev->res[i].xa; - if (!xa_empty(xa)) { - unsigned long index; - - if (!found) { - pr_err("restrack: %s", CUT_HERE); - dev_err(&dev->dev, "BUG: RESTRACK detected leak of resources\n"); - } - xa_for_each(xa, index, e) { - if (rdma_is_kernel_res(e)) { - owner = e->kern_name; - } else { - /* - * There is no need to call get_task_struct here, - * because we can be here only if there are more - * get_task_struct() call than put_task_struct(). - */ - get_task_comm(buf, e->task); - owner = buf; - } - - pr_err("restrack: %s %s object allocated by %s is not freed\n", - rdma_is_kernel_res(e) ? "Kernel" : - "User", - type2str(e->type), owner); - } - found = true; - } + WARN_ON(!xa_empty(xa)); xa_destroy(xa); } - if (found) - pr_err("restrack: %s", CUT_HERE); - kfree(rt); } -- 2.34.1

2 1

[PATCH] s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception()
by Huang Xiaojia 03 Aug '24

03 Aug '24

From: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> mainline inclusion from mainline-v6.11-rc1 commit df39038cd89525d465c2c8827eb64116873f141a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF2 CVE: CVE-2024-41021 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on s390. Therefore we do not expect to see VM_FAULT_HWPOISON in do_exception(). However, since commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general"), it is possible to see VM_FAULT_HWPOISON in combination with PTE_MARKER_POISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in do_exception(). Fix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging. Note that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level. Cc: stable(a)vger.kernel.org # 6.6+ Fixes: af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more general") Reported-by: Yunseong Kim <yskelg(a)gmail.com> Tested-by: Yunseong Kim <yskelg(a)gmail.com> Acked-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Message-ID: <20240715180416.3632453-1-gerald.schaefer(a)linux.ibm.com> Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com> Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/s390/mm/fault.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c index f5463535013a..0f3ce563056f 100644 --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -331,14 +331,16 @@ static noinline void do_fault_error(struct pt_regs *regs, vm_fault_t fault) do_no_context(regs, fault); else do_sigsegv(regs, SEGV_MAPERR); - } else if (fault & VM_FAULT_SIGBUS) { + } else if (fault & (VM_FAULT_SIGBUS | VM_FAULT_HWPOISON)) { /* Kernel mode? Handle exceptions or die */ if (!user_mode(regs)) do_no_context(regs, fault); else do_sigbus(regs); - } else + } else { + pr_emerg("Unexpected fault flags: %08x\n", fault); BUG(); + } break; } } -- 2.34.1

1 0

[PATCH OLK-6.6] nvme: avoid double free special payload
by Li Lingfeng 03 Aug '24

03 Aug '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> stable inclusion from stable-v6.6.42 commit ae84383c96d6662c24697ab6b44aae855ab670aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEML CVE: CVE-2024-41073 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit e5d574ab37f5f2e7937405613d9b1a724811e5ad ] If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Max Gurtovoy <mgurtovoy(a)nvidia.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/nvme/host/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 94a0916f9cb7..e969da0a681b 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -938,6 +938,7 @@ void nvme_cleanup_cmd(struct request *req) clear_bit_unlock(0, &ctrl->discard_page_busy); else kfree(bvec_virt(&req->special_vec)); + req->rq_flags &= ~RQF_SPECIAL_PAYLOAD; } } EXPORT_SYMBOL_GPL(nvme_cleanup_cmd); -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS 1/1] usb: atm: cxacru: fix endpoint checking in cxacru_bind()
by Luo Gengkun 03 Aug '24

03 Aug '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc6 commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEOL CVE: CVE-2024-41097 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 Reported-and-tested-by: syzbot+00c18ee8497dd3be6ade(a)syzkaller.appspotmail.com Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint") Cc: stable <stable(a)kernel.org> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240609131546.3932-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/usb/atm/cxacru.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c index e62a770a5d3b..1d2c736dbf6a 100644 --- a/drivers/usb/atm/cxacru.c +++ b/drivers/usb/atm/cxacru.c @@ -1134,6 +1134,7 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, struct cxacru_data *instance; struct usb_device *usb_dev = interface_to_usbdev(intf); struct usb_host_endpoint *cmd_ep = usb_dev->ep_in[CXACRU_EP_CMD]; + struct usb_endpoint_descriptor *in, *out; int ret; /* instance init */ @@ -1180,6 +1181,19 @@ static int cxacru_bind(struct usbatm_data *usbatm_instance, goto fail; } + if (usb_endpoint_xfer_int(&cmd_ep->desc)) + ret = usb_find_common_endpoints(intf->cur_altsetting, + NULL, NULL, &in, &out); + else + ret = usb_find_common_endpoints(intf->cur_altsetting, + &in, &out, NULL, NULL); + + if (ret) { + usb_err(usbatm_instance, "cxacru_bind: interface has incorrect endpoints\n"); + ret = -ENODEV; + goto fail; + } + if ((cmd_ep->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) { usb_fill_int_urb(instance->rcv_urb, -- 2.34.1

2 1

[PATCH OLK-6.6] s390/pkey: Wipe copies of clear-key structures on failure
by Li Huafei 03 Aug '24

03 Aug '24

From: Holger Dengler <dengler(a)linux.ibm.com> mainline inclusion from mainline-v6.10-rc1 commit d65d76a44ffe74c73298ada25b0f578680576073 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAH6LY CVE: CVE-2024-42156 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key. Reviewed-by: Harald Freudenberger <freude(a)linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki(a)linux.ibm.com> Acked-by: Heiko Carstens <hca(a)linux.ibm.com> Signed-off-by: Holger Dengler <dengler(a)linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Conflicts: drivers/s390/crypto/pkey_api.c [ Resolved context conflict due to commit 6d749b4e0208 ("s390/pkey: introduce dynamic debugging for pkey") not backport. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/s390/crypto/pkey_api.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c index d2ffdf2491da..70fcb5c40cfe 100644 --- a/drivers/s390/crypto/pkey_api.c +++ b/drivers/s390/crypto/pkey_api.c @@ -1366,9 +1366,7 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, rc = cca_clr2seckey(kcs.cardnr, kcs.domain, kcs.keytype, kcs.clrkey.clrkey, kcs.seckey.seckey); DEBUG_DBG("%s cca_clr2seckey()=%d\n", __func__, rc); - if (rc) - break; - if (copy_to_user(ucs, &kcs, sizeof(kcs))) + if (!rc && copy_to_user(ucs, &kcs, sizeof(kcs))) rc = -EFAULT; memzero_explicit(&kcs, sizeof(kcs)); break; @@ -1401,9 +1399,7 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, kcp.protkey.protkey, &kcp.protkey.len, &kcp.protkey.type); DEBUG_DBG("%s pkey_clr2protkey()=%d\n", __func__, rc); - if (rc) - break; - if (copy_to_user(ucp, &kcp, sizeof(kcp))) + if (!rc && copy_to_user(ucp, &kcp, sizeof(kcp))) rc = -EFAULT; memzero_explicit(&kcp, sizeof(kcp)); break; @@ -1555,11 +1551,14 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, if (copy_from_user(&kcs, ucs, sizeof(kcs))) return -EFAULT; apqns = _copy_apqns_from_user(kcs.apqns, kcs.apqn_entries); - if (IS_ERR(apqns)) + if (IS_ERR(apqns)) { + memzero_explicit(&kcs, sizeof(kcs)); return PTR_ERR(apqns); + } kkey = kzalloc(klen, GFP_KERNEL); if (!kkey) { kfree(apqns); + memzero_explicit(&kcs, sizeof(kcs)); return -ENOMEM; } rc = pkey_clr2seckey2(apqns, kcs.apqn_entries, @@ -1569,15 +1568,18 @@ static long pkey_unlocked_ioctl(struct file *filp, unsigned int cmd, kfree(apqns); if (rc) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); break; } if (kcs.key) { if (kcs.keylen < klen) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); return -EINVAL; } if (copy_to_user(kcs.key, kkey, klen)) { kfree(kkey); + memzero_explicit(&kcs, sizeof(kcs)); return -EFAULT; } } -- 2.25.1

2 1

[PATCH OLK-5.10] mm: thp: support to control numa migration
by Nanyong Sun 03 Aug '24

03 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 interface to contrl THP migration when do numa balancing: /sys/kernel/mm/transparent_hugepage/numa_control Default value is 0 which means do nothing. Write 1 to disable migrate THP while task still have chance to migrate. Write 2 to disable autonuma for THP totally. Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 9 ++++++ arch/arm64/Kconfig | 1 + include/linux/huge_mm.h | 24 +++++++++++++++ mm/Kconfig | 10 ++++++ mm/huge_memory.c | 36 ++++++++++++++++++++++ mm/mem_sampling.c | 3 ++ mm/migrate.c | 3 ++ 7 files changed, 86 insertions(+) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2bfb380e8380..1038ff8e184d 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -160,6 +160,15 @@ library) may want to know the size (in bytes) of a transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size +If CONFIG_THP_NUMA_CONTROL is on, user can control THP migration when +do numa balancing, 0 is default which means keep the default behavior, +writing 1 will disable thp migrate while tasks still have chance to +migrate, writing 2 will skip THP totally from numa balancing:: + + echo 0 > /sys/kernel/mm/transparent_hugepage/numa_control + echo 1 > /sys/kernel/mm/transparent_hugepage/numa_control + echo 2 > /sys/kernel/mm/transparent_hugepage/numa_control + 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..bde9ec4af773 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 THP_NUMA_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..c2bf15d2d969 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -498,6 +498,30 @@ static inline unsigned long thp_size(struct page *page) return PAGE_SIZE << thp_order(page); } +#ifdef CONFIG_THP_NUMA_CONTROL +#define THP_DISABLE_NUMA_MIGRATE 1 +#define THP_DISABLE_AUTONUMA 2 +extern unsigned long thp_numa_control; +static inline bool thp_numa_migrate_disabled(void) +{ + return thp_numa_control == THP_DISABLE_NUMA_MIGRATE; +} + +static inline bool thp_autonuma_disabled(void) +{ + return thp_numa_control == THP_DISABLE_AUTONUMA; +} +#else +static inline bool thp_numa_migrate_disabled(void) +{ + return false; +} + +static inline bool thp_numa_migrate_disabled(void) +{ + return false; +} +#endif /* * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to * limitations in the implementation like arm64 MTE can override this to diff --git a/mm/Kconfig b/mm/Kconfig index ccbad233f2b1..cc43f5124cb3 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 THP_NUMA_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..332f712906e1 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -316,6 +316,36 @@ 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_THP_NUMA_CONTROL +unsigned long thp_numa_control; + +static ssize_t numa_control_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return sprintf(buf, "%lu\n", thp_numa_control); +} + +static ssize_t numa_control_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) +{ + unsigned long value; + int ret; + + ret = kstrtoul(buf, 10, &value); + if (ret < 0) + return ret; + if (value > THP_DISABLE_AUTONUMA) + return -EINVAL; + + thp_numa_control = value; + + return count; +} + +static struct kobj_attribute numa_control_attr = + __ATTR(numa_control, 0644, numa_control_show, numa_control_store); +#endif + static struct attribute *hugepage_attr[] = { &enabled_attr.attr, &defrag_attr.attr, @@ -323,6 +353,9 @@ static struct attribute *hugepage_attr[] = { &hpage_pmd_size_attr.attr, #ifdef CONFIG_SHMEM &shmem_enabled_attr.attr, +#endif +#ifdef CONFIG_THP_NUMA_CONTROL + &numa_control_attr.attr, #endif NULL, }; @@ -1743,6 +1776,9 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd, if (prot_numa && !thp_migration_supported()) return 1; + if (prot_numa && thp_autonuma_disabled()) + return 1; + ptl = __pmd_trans_huge_lock(pmd, vma); if (!ptl) return 0; diff --git a/mm/mem_sampling.c b/mm/mem_sampling.c index 1d8a831be531..ffc0e4964cad 100644 --- a/mm/mem_sampling.c +++ b/mm/mem_sampling.c @@ -145,6 +145,9 @@ static inline void do_thp_numa_access(struct mm_struct *mm, pmd_t *pmd, pmde; spinlock_t *ptl; + if (thp_autonuma_disabled()) + return; + pgd = pgd_offset(mm, vaddr); if (!pgd_present(*pgd)) return; diff --git a/mm/migrate.c b/mm/migrate.c index 3f5b217d5af1..faaa7b790da0 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_numa_migrate_disabled()) + return 0; + if (compound) new = alloc_misplaced_dst_page_thp; else -- 2.25.1

2 1

[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 Conflicts: kernel/sched/deadline.c [remove !dl_server(&p->dl) condition] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..cff58dba27ff 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,12 @@ 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) + 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 Conflicts: kernel/sched/deadline.c [remove !dl_server(&p->dl) condition] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..cff58dba27ff 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,12 @@ 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) + 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 Conflicts: kernel/sched/deadline.c [remove !dl_server(&p->dl) condition] Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/deadline.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 71b55d9de2d9..cff58dba27ff 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1528,8 +1528,12 @@ 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) + put_task_struct(p); p->dl.dl_throttled = 0; } } else if (!dl_prio(p->normal_prio)) { -- 2.34.1

2 1

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

03 Aug '24

From: Edward Adam Davis <eadavis(a)qq.com> 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 v2 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> 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-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

[PATCH OLK-5.10] 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

[PATCH OLK-5.10 v2] bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
by Pu Lehui 02 Aug '24

02 Aug '24

From: "Jose E. Marchesi" <jose.marchesi(a)oracle.com> stable inclusion from stable-v5.10.222 commit b694989bb13ed5f166e633faa1eb0f21c6d261a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGRP3 CVE: CVE-2024-42161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ] [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. Signed-off-by: Jose E. Marchesi <jose.marchesi(a)oracle.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- tools/lib/bpf/bpf_core_read.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h index f05cfc082915..4303b31498d8 100644 --- a/tools/lib/bpf/bpf_core_read.h +++ b/tools/lib/bpf/bpf_core_read.h @@ -101,6 +101,7 @@ enum bpf_enum_value_kind { case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ + default: val = 0; break; \ } \ val <<= __CORE_RELO(s, field, LSHIFT_U64); \ if (__CORE_RELO(s, field, SIGNED)) \ -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 v2] bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
by Pu Lehui 02 Aug '24

02 Aug '24

From: "Jose E. Marchesi" <jose.marchesi(a)oracle.com> stable inclusion from stable-v5.10.222 commit b694989bb13ed5f166e633faa1eb0f21c6d261a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGRP3 CVE: CVE-2024-42161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ] [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. Signed-off-by: Jose E. Marchesi <jose.marchesi(a)oracle.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- tools/lib/bpf/bpf_core_read.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h index f05cfc082915..4303b31498d8 100644 --- a/tools/lib/bpf/bpf_core_read.h +++ b/tools/lib/bpf/bpf_core_read.h @@ -101,6 +101,7 @@ enum bpf_enum_value_kind { case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ + default: val = 0; break; \ } \ val <<= __CORE_RELO(s, field, LSHIFT_U64); \ if (__CORE_RELO(s, field, SIGNED)) \ -- 2.34.1

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..16ebce97bfbe 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2530,8 +2530,9 @@ int fcntl_setlk(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 && @@ -2545,9 +2546,7 @@ int fcntl_setlk(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/3] 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 include/net/bluetooth/hci_sync.h | 2 + net/bluetooth/hci_core.c | 69 +++++++------------------------- net/bluetooth/hci_sync.c | 13 ++++++ net/bluetooth/l2cap_core.c | 3 ++ net/bluetooth/l2cap_sock.c | 14 +++++-- 5 files changed, 44 insertions(+), 57 deletions(-) -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1 0/3] 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 net/bluetooth/hci_core.c | 69 +++++++++----------------------------- net/bluetooth/l2cap_core.c | 3 ++ net/bluetooth/l2cap_sock.c | 10 +++++- 3 files changed, 27 insertions(+), 55 deletions(-) -- 2.34.1

2 5

[PATCH OLK-6.6 0/2] CVE-2024-35860
by Pu Lehui 02 Aug '24

02 Aug '24

Andrii Nakryiko (1): bpf: support deferring bpf_link dealloc to after RCU grace period Tengda Wu (1): Fix kabi breakage in struct bpf_link and bpf_link_ops include/linux/bpf.h | 17 +++++++++++++++-- kernel/bpf/syscall.c | 35 ++++++++++++++++++++++++++++++++--- kernel/trace/bpf_trace.c | 4 ++-- 3 files changed, 49 insertions(+), 7 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10 0/3] 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 net/bluetooth/hci_core.c | 69 +++++++++----------------------------- net/bluetooth/l2cap_core.c | 3 ++ net/bluetooth/l2cap_sock.c | 10 +++++- 3 files changed, 27 insertions(+), 55 deletions(-) -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1] bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
by Pu Lehui 02 Aug '24

02 Aug '24

From: "Jose E. Marchesi" <jose.marchesi(a)oracle.com> stable inclusion from stable-v5.10.222 commit b694989bb13ed5f166e633faa1eb0f21c6d261a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAHF4L Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ] [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. Signed-off-by: Jose E. Marchesi <jose.marchesi(a)oracle.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- tools/lib/bpf/bpf_core_read.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h index f05cfc082915..4303b31498d8 100644 --- a/tools/lib/bpf/bpf_core_read.h +++ b/tools/lib/bpf/bpf_core_read.h @@ -101,6 +101,7 @@ enum bpf_enum_value_kind { case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ + default: val = 0; break; \ } \ val <<= __CORE_RELO(s, field, LSHIFT_U64); \ if (__CORE_RELO(s, field, SIGNED)) \ -- 2.34.1

2 1

[PATCH OLK-5.10] bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
by Pu Lehui 02 Aug '24

02 Aug '24

From: "Jose E. Marchesi" <jose.marchesi(a)oracle.com> stable inclusion from stable-v5.10.222 commit b694989bb13ed5f166e633faa1eb0f21c6d261a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAHF4L Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ] [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. Signed-off-by: Jose E. Marchesi <jose.marchesi(a)oracle.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- tools/lib/bpf/bpf_core_read.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h index f05cfc082915..4303b31498d8 100644 --- a/tools/lib/bpf/bpf_core_read.h +++ b/tools/lib/bpf/bpf_core_read.h @@ -101,6 +101,7 @@ enum bpf_enum_value_kind { case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ + default: val = 0; break; \ } \ val <<= __CORE_RELO(s, field, LSHIFT_U64); \ if (__CORE_RELO(s, field, SIGNED)) \ -- 2.34.1

2 1

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

02 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): coda part1 arch/arm64/Kconfig | 8 + arch/arm64/configs/openeuler_defconfig | 5 +- arch/arm64/include/asm/kvm_emulate.h | 18 + arch/arm64/include/asm/kvm_host.h | 15 +- arch/arm64/include/asm/kvm_tmi.h | 410 +++++++ arch/arm64/include/asm/kvm_tmm.h | 52 +- arch/arm64/include/asm/set_memory.h | 1 + arch/arm64/include/asm/virtcca_cvm_guest.h | 39 + arch/arm64/include/uapi/asm/kvm.h | 4 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/virtcca_cvm_guest.c | 93 ++ arch/arm64/kvm/Kconfig | 6 +- arch/arm64/kvm/Makefile | 3 + arch/arm64/kvm/arch_timer.c | 92 ++ arch/arm64/kvm/arm.c | 136 ++- arch/arm64/kvm/guest.c | 8 + arch/arm64/kvm/mmio.c | 17 +- arch/arm64/kvm/mmu.c | 30 + arch/arm64/kvm/pmu-emul.c | 9 + arch/arm64/kvm/psci.c | 12 +- arch/arm64/kvm/reset.c | 13 + arch/arm64/kvm/tmi.c | 279 +++++ arch/arm64/kvm/vgic/vgic-v3.c | 17 +- arch/arm64/kvm/vgic/vgic.c | 55 +- arch/arm64/kvm/virtcca_cvm.c | 1065 +++++++++++++++++ arch/arm64/kvm/virtcca_cvm_exit.c | 221 ++++ arch/arm64/mm/init.c | 3 + arch/arm64/mm/mmu.c | 5 +- arch/arm64/mm/pageattr.c | 3 + drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 809 +++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 +++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 178 ++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/iommu/io-pgtable-arm.c | 60 + drivers/iommu/iommu.c | 11 + drivers/irqchip/irq-gic-v3-its.c | 231 +++- drivers/pci/access.c | 33 + drivers/pci/msi/msi.c | 90 +- drivers/perf/arm_pmu.c | 17 + drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 + drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/kvm/arm_arch_timer.h | 4 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/kvm_host.h | 22 + include/linux/pci.h | 4 + include/linux/perf/arm_pmu.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/kvm.h | 13 + include/uapi/linux/vfio.h | 3 + kernel/dma/swiotlb.c | 16 + virt/kvm/kvm_main.c | 4 + virt/kvm/vfio.c | 121 +- virt/kvm/vfio.h | 10 + 57 files changed, 4511 insertions(+), 69 deletions(-) create mode 100644 arch/arm64/include/asm/kvm_tmi.h create mode 100644 arch/arm64/include/asm/virtcca_cvm_guest.h create mode 100644 arch/arm64/kernel/virtcca_cvm_guest.c create mode 100644 arch/arm64/kvm/tmi.c create mode 100644 arch/arm64/kvm/virtcca_cvm.c create mode 100644 arch/arm64/kvm/virtcca_cvm_exit.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

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

02 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): coda part1 arch/arm64/Kconfig | 8 + arch/arm64/configs/openeuler_defconfig | 5 +- arch/arm64/include/asm/kvm_emulate.h | 18 + arch/arm64/include/asm/kvm_host.h | 15 +- arch/arm64/include/asm/kvm_tmi.h | 410 +++++++ arch/arm64/include/asm/kvm_tmm.h | 52 +- arch/arm64/include/asm/set_memory.h | 1 + arch/arm64/include/asm/virtcca_cvm_guest.h | 39 + arch/arm64/include/uapi/asm/kvm.h | 4 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/virtcca_cvm_guest.c | 93 ++ arch/arm64/kvm/Kconfig | 6 +- arch/arm64/kvm/Makefile | 3 + arch/arm64/kvm/arch_timer.c | 92 ++ arch/arm64/kvm/arm.c | 136 ++- arch/arm64/kvm/guest.c | 8 + arch/arm64/kvm/mmio.c | 17 +- arch/arm64/kvm/mmu.c | 30 + arch/arm64/kvm/pmu-emul.c | 9 + arch/arm64/kvm/psci.c | 12 +- arch/arm64/kvm/reset.c | 13 + arch/arm64/kvm/tmi.c | 279 +++++ arch/arm64/kvm/vgic/vgic-v3.c | 17 +- arch/arm64/kvm/vgic/vgic.c | 55 +- arch/arm64/kvm/virtcca_cvm.c | 1065 +++++++++++++++++ arch/arm64/kvm/virtcca_cvm_exit.c | 221 ++++ arch/arm64/mm/init.c | 3 + arch/arm64/mm/mmu.c | 5 +- arch/arm64/mm/pageattr.c | 3 + drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 809 +++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 +++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 178 ++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/iommu/io-pgtable-arm.c | 60 + drivers/iommu/iommu.c | 11 + drivers/irqchip/irq-gic-v3-its.c | 231 +++- drivers/pci/access.c | 33 + drivers/pci/msi/msi.c | 90 +- drivers/perf/arm_pmu.c | 17 + drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 + drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/kvm/arm_arch_timer.h | 4 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/kvm_host.h | 22 + include/linux/pci.h | 4 + include/linux/perf/arm_pmu.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/kvm.h | 13 + include/uapi/linux/vfio.h | 3 + kernel/dma/swiotlb.c | 16 + virt/kvm/kvm_main.c | 4 + virt/kvm/vfio.c | 121 +- virt/kvm/vfio.h | 10 + 57 files changed, 4511 insertions(+), 69 deletions(-) create mode 100644 arch/arm64/include/asm/kvm_tmi.h create mode 100644 arch/arm64/include/asm/virtcca_cvm_guest.h create mode 100644 arch/arm64/kernel/virtcca_cvm_guest.c create mode 100644 arch/arm64/kvm/tmi.c create mode 100644 arch/arm64/kvm/virtcca_cvm.c create mode 100644 arch/arm64/kvm/virtcca_cvm_exit.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 4

[PATCH openEuler-1.0-LTS] ila: block BH in ila_output()
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.319 commit 7435bd2f84a25aba607030237261b3795ba782da category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMQ CVE: CVE-2024-41081 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit cf28ff8e4c02e1ffa850755288ac954b6ff0db8c ] As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable(). Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/20240531132636.2637995-5-edumazet@google.com 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> --- net/ipv6/ila/ila_lwt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ila/ila_lwt.c b/net/ipv6/ila/ila_lwt.c index 3d56a2fb6f86..c7630776bd8e 100644 --- a/net/ipv6/ila/ila_lwt.c +++ b/net/ipv6/ila/ila_lwt.c @@ -58,7 +58,9 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) return orig_dst->lwtstate->orig_output(net, sk, skb); } + local_bh_disable(); dst = dst_cache_get(&ilwt->dst_cache); + local_bh_enable(); if (unlikely(!dst)) { struct ipv6hdr *ip6h = ipv6_hdr(skb); struct flowi6 fl6; @@ -86,8 +88,11 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) goto drop; } - if (ilwt->connected) + if (ilwt->connected) { + local_bh_disable(); dst_cache_set_ip6(&ilwt->dst_cache, dst, &fl6.saddr); + local_bh_enable(); + } } skb_dst_set(skb, dst); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ila: block BH in ila_output()
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.223 commit a0cafb7b0b94d18e4813ee4b712a056f280e7b5a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMQ CVE: CVE-2024-41081 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit cf28ff8e4c02e1ffa850755288ac954b6ff0db8c ] As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable(). Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/20240531132636.2637995-5-edumazet@google.com 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> --- net/ipv6/ila/ila_lwt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ila/ila_lwt.c b/net/ipv6/ila/ila_lwt.c index 8c1ce78956ba..9d37f7164e73 100644 --- a/net/ipv6/ila/ila_lwt.c +++ b/net/ipv6/ila/ila_lwt.c @@ -58,7 +58,9 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) return orig_dst->lwtstate->orig_output(net, sk, skb); } + local_bh_disable(); dst = dst_cache_get(&ilwt->dst_cache); + local_bh_enable(); if (unlikely(!dst)) { struct ipv6hdr *ip6h = ipv6_hdr(skb); struct flowi6 fl6; @@ -86,8 +88,11 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) goto drop; } - if (ilwt->connected) + if (ilwt->connected) { + local_bh_disable(); dst_cache_set_ip6(&ilwt->dst_cache, dst, &fl6.saddr); + local_bh_enable(); + } } skb_dst_set(skb, dst); -- 2.34.1

2 1

[PATCH OLK-5.10] ila: block BH in ila_output()
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.223 commit a0cafb7b0b94d18e4813ee4b712a056f280e7b5a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMQ CVE: CVE-2024-41081 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit cf28ff8e4c02e1ffa850755288ac954b6ff0db8c ] As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable(). Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/20240531132636.2637995-5-edumazet@google.com 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> --- net/ipv6/ila/ila_lwt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ila/ila_lwt.c b/net/ipv6/ila/ila_lwt.c index 8c1ce78956ba..9d37f7164e73 100644 --- a/net/ipv6/ila/ila_lwt.c +++ b/net/ipv6/ila/ila_lwt.c @@ -58,7 +58,9 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) return orig_dst->lwtstate->orig_output(net, sk, skb); } + local_bh_disable(); dst = dst_cache_get(&ilwt->dst_cache); + local_bh_enable(); if (unlikely(!dst)) { struct ipv6hdr *ip6h = ipv6_hdr(skb); struct flowi6 fl6; @@ -86,8 +88,11 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) goto drop; } - if (ilwt->connected) + if (ilwt->connected) { + local_bh_disable(); dst_cache_set_ip6(&ilwt->dst_cache, dst, &fl6.saddr); + local_bh_enable(); + } } skb_dst_set(skb, dst); -- 2.34.1

2 1

[PATCH OLK-6.6] ila: block BH in ila_output()
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.42 commit 522c3336c2025818fa05e9daf0ac35711e55e316 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMQ CVE: CVE-2024-41081 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit cf28ff8e4c02e1ffa850755288ac954b6ff0db8c ] As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable(). Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/20240531132636.2637995-5-edumazet@google.com 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> --- net/ipv6/ila/ila_lwt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ila/ila_lwt.c b/net/ipv6/ila/ila_lwt.c index 8c1ce78956ba..9d37f7164e73 100644 --- a/net/ipv6/ila/ila_lwt.c +++ b/net/ipv6/ila/ila_lwt.c @@ -58,7 +58,9 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) return orig_dst->lwtstate->orig_output(net, sk, skb); } + local_bh_disable(); dst = dst_cache_get(&ilwt->dst_cache); + local_bh_enable(); if (unlikely(!dst)) { struct ipv6hdr *ip6h = ipv6_hdr(skb); struct flowi6 fl6; @@ -86,8 +88,11 @@ static int ila_output(struct net *net, struct sock *sk, struct sk_buff *skb) goto drop; } - if (ilwt->connected) + if (ilwt->connected) { + local_bh_disable(); dst_cache_set_ip6(&ilwt->dst_cache, dst, &fl6.saddr); + local_bh_enable(); + } } skb_dst_set(skb, dst); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] gpio: davinci: Validate the obtained number of IRQs
by heyujie 02 Aug '24

02 Aug '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc6 commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP8 CVE: CVE-2024-42092 Reference: http://hulk.rnd.huawei.com/patch/detail/7aa9b96e9a73e4ec1771492d0527bd5fc5e… -------------------------------- Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Link: https://lore.kernel.org/r/20240618144344.16943-1-amishin@t-argos.ru Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpio/gpio-davinci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index 6f2138503726..764c5b86043e 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -227,6 +227,11 @@ static int davinci_gpio_probe(struct platform_device *pdev) else nirq = DIV_ROUND_UP(ngpio, 16); + if (nirq > MAX_INT_PER_BANK) { + dev_err(dev, "Too many IRQs!\n"); + return -EINVAL; + } + chips = devm_kzalloc(dev, sizeof(*chips), GFP_KERNEL); if (!chips) return -ENOMEM; -- 2.34.1

2 1

[PATCH OLK-5.10] gpio: davinci: Validate the obtained number of IRQs
by heyujie 02 Aug '24

02 Aug '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc6 commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP8 CVE: CVE-2024-42092 Reference: http://hulk.rnd.huawei.com/patch/detail/7aa9b96e9a73e4ec1771492d0527bd5fc5e… -------------------------------- Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Link: https://lore.kernel.org/r/20240618144344.16943-1-amishin@t-argos.ru Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpio/gpio-davinci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index 80597e90de9c..33623bcfc886 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -227,6 +227,11 @@ static int davinci_gpio_probe(struct platform_device *pdev) else nirq = DIV_ROUND_UP(ngpio, 16); + if (nirq > MAX_INT_PER_BANK) { + dev_err(dev, "Too many IRQs!\n"); + return -EINVAL; + } + chips = devm_kzalloc(dev, sizeof(*chips), GFP_KERNEL); if (!chips) return -ENOMEM; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] gpio: davinci: Validate the obtained number of IRQs
by heyujie 02 Aug '24

02 Aug '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc6 commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP8 CVE: CVE-2024-42092 Reference: http://hulk.rnd.huawei.com/patch/detail/7aa9b96e9a73e4ec1771492d0527bd5fc5e… -------------------------------- Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Link: https://lore.kernel.org/r/20240618144344.16943-1-amishin@t-argos.ru Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpio/gpio-davinci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index abb332d15a13..b77e1c6b099e 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -207,6 +207,11 @@ static int davinci_gpio_probe(struct platform_device *pdev) else nirq = DIV_ROUND_UP(ngpio, 16); + if (nirq > MAX_INT_PER_BANK) { + dev_err(dev, "Too many IRQs!\n"); + return -EINVAL; + } + nbank = DIV_ROUND_UP(ngpio, 32); chips = devm_kcalloc(dev, nbank, sizeof(struct davinci_gpio_controller), -- 2.34.1

2 1

[PATCH OLK-5.10] net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Oleksij Rempel <o.rempel(a)pengutronix.de> stable inclusion from stable-v5.10.221 commit f6c839e717901dbd6b1c1ca807b6210222eb70f6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAH95F CVE: CVE-2023-52887 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream. This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Reported-by: syzbot+daa36413a5cedf799ae4(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/can/j1939/transport.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 5dcbb0b7d123..c9e61963288c 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1577,8 +1577,8 @@ j1939_session *j1939_xtp_rx_rts_session_new(struct j1939_priv *priv, struct j1939_sk_buff_cb skcb = *j1939_skb_to_cb(skb); struct j1939_session *session; const u8 *dat; + int len, ret; pgn_t pgn; - int len; netdev_dbg(priv->ndev, "%s\n", __func__); @@ -1634,7 +1634,22 @@ j1939_session *j1939_xtp_rx_rts_session_new(struct j1939_priv *priv, session->pkt.rx = 0; session->pkt.tx = 0; - WARN_ON_ONCE(j1939_session_activate(session)); + ret = j1939_session_activate(session); + if (ret) { + /* Entering this scope indicates an issue with the J1939 bus. + * Possible scenarios include: + * - A time lapse occurred, and a new session was initiated + * due to another packet being sent correctly. This could + * have been caused by too long interrupt, debugger, or being + * out-scheduled by another task. + * - The bus is receiving numerous erroneous packets, either + * from a malfunctioning device or during a test scenario. + */ + netdev_alert(priv->ndev, "%s: 0x%p: concurrent session with same addr (%02x %02x) is already active.\n", + __func__, session, skcb.addr.sa, skcb.addr.da); + j1939_session_put(session); + return NULL; + } return session; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Oleksij Rempel <o.rempel(a)pengutronix.de> stable inclusion from stable-v5.10.221 commit f6c839e717901dbd6b1c1ca807b6210222eb70f6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAH95F CVE: CVE-2023-52887 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream. This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Reported-by: syzbot+daa36413a5cedf799ae4(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/can/j1939/transport.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 2830a12a4dd1..718f70d51068 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1576,8 +1576,8 @@ j1939_session *j1939_xtp_rx_rts_session_new(struct j1939_priv *priv, struct j1939_sk_buff_cb skcb = *j1939_skb_to_cb(skb); struct j1939_session *session; const u8 *dat; + int len, ret; pgn_t pgn; - int len; netdev_dbg(priv->ndev, "%s\n", __func__); @@ -1633,7 +1633,22 @@ j1939_session *j1939_xtp_rx_rts_session_new(struct j1939_priv *priv, session->pkt.rx = 0; session->pkt.tx = 0; - WARN_ON_ONCE(j1939_session_activate(session)); + ret = j1939_session_activate(session); + if (ret) { + /* Entering this scope indicates an issue with the J1939 bus. + * Possible scenarios include: + * - A time lapse occurred, and a new session was initiated + * due to another packet being sent correctly. This could + * have been caused by too long interrupt, debugger, or being + * out-scheduled by another task. + * - The bus is receiving numerous erroneous packets, either + * from a malfunctioning device or during a test scenario. + */ + netdev_alert(priv->ndev, "%s: 0x%p: concurrent session with same addr (%02x %02x) is already active.\n", + __func__, session, skcb.addr.sa, skcb.addr.da); + j1939_session_put(session); + return NULL; + } return session; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] nilfs2: add missing check for inode numbers on directory entries
by Xia Fukun 02 Aug '24

02 Aug '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v5.10.223 commit 2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGPRT CVE: CVE-2024-42104 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit bb76c6c274683c8570ad788f79d4b875bde0e458 upstream. Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. Link: https://lkml.kernel.org/r/20240623051135.4180-3-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+d79afb004be235636ee8(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d79afb004be235636ee8 Reported-by: Jan Kara <jack(a)suse.cz> Closes: https://lkml.kernel.org/r/20240617075758.wewhukbrjod5fp5o@quack3 Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: Hillf Danton <hdanton(a)sina.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- fs/nilfs2/dir.c | 6 ++++++ fs/nilfs2/nilfs.h | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/fs/nilfs2/dir.c b/fs/nilfs2/dir.c index eb7de9e2a384e..1f9e31d285cc9 100644 --- a/fs/nilfs2/dir.c +++ b/fs/nilfs2/dir.c @@ -143,6 +143,9 @@ static bool nilfs_check_page(struct page *page) goto Enamelen; if (((offs + rec_len - 1) ^ offs) & ~(chunk_size-1)) goto Espan; + if (unlikely(p->inode && + NILFS_PRIVATE_INODE(le64_to_cpu(p->inode)))) + goto Einumber; } if (offs != limit) goto Eend; @@ -168,6 +171,9 @@ static bool nilfs_check_page(struct page *page) goto bad_entry; Espan: error = "directory entry across blocks"; + goto bad_entry; +Einumber: + error = "disallowed inode number"; bad_entry: nilfs_error(sb, "bad entry in directory #%lu: %s - offset=%lu, inode=%lu, rec_len=%d, name_len=%d", diff --git a/fs/nilfs2/nilfs.h b/fs/nilfs2/nilfs.h index a2f247b6a209e..986620709b9de 100644 --- a/fs/nilfs2/nilfs.h +++ b/fs/nilfs2/nilfs.h @@ -125,6 +125,11 @@ enum { #define NILFS_VALID_INODE(sb, ino) \ ((ino) >= NILFS_FIRST_INO(sb) || (NILFS_SYS_INO_BITS & BIT(ino))) +#define NILFS_PRIVATE_INODE(ino) ({ \ + ino_t __ino = (ino); \ + ((__ino) < NILFS_USER_INO && (__ino) != NILFS_ROOT_INO && \ + (__ino) != NILFS_SKETCH_INO); }) + /** * struct nilfs_transaction_info: context information for synchronization * @ti_magic: Magic number -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] bluetooth/l2cap: sync sock recv cb and release
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Edward Adam Davis <eadavis(a)qq.com> mainline inclusion from mainline-v6.10-rc7 commit 89e856e124f9ae548572c56b1b70c2255705f8fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEK1 CVE: CVE-2024-41062 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. Reported-and-tested-by: syzbot+b7f6f8c9303466e16c8a(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/l2cap_sock.c [The conflict occurs because the commit 89e856e124f9("bluetooth/l2cap: sync sock recv cb and release") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/bluetooth/l2cap_sock.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index c91f4c190bbc..c7217d3ecd8b 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1238,6 +1238,10 @@ static void l2cap_sock_kill(struct sock *sk) BT_DBG("sk %p state %s", sk, state_to_string(sk->sk_state)); + /* Sock is dead, so set chan data to NULL, avoid other task use invalid + * sock pointer. + */ + l2cap_pi(sk)->chan->data = NULL; /* Kill poor orphan */ l2cap_chan_put(l2cap_pi(sk)->chan); @@ -1480,9 +1484,21 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan) static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb) { - struct sock *sk = chan->data; + struct sock *sk; int err; + /* To avoid race with sock_release, a chan lock needs to be added here + * to synchronize the sock. + */ + l2cap_chan_hold(chan); + l2cap_chan_lock(chan); + sk = chan->data; + if (!sk) { + l2cap_chan_unlock(chan); + l2cap_chan_put(chan); + return -ENXIO; + } + lock_sock(sk); if (l2cap_pi(sk)->rx_busy_skb) { @@ -1519,6 +1535,8 @@ static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb) done: release_sock(sk); + l2cap_chan_unlock(chan); + l2cap_chan_put(chan); return err; } -- 2.34.1

2 1

[PATCH OLK-5.10] bluetooth/l2cap: sync sock recv cb and release
by Zhengchao Shao 02 Aug '24

02 Aug '24

From: Edward Adam Davis <eadavis(a)qq.com> mainline inclusion from mainline-v6.10-rc7 commit 89e856e124f9ae548572c56b1b70c2255705f8fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEK1 CVE: CVE-2024-41062 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. Reported-and-tested-by: syzbot+b7f6f8c9303466e16c8a(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/l2cap_sock.c [The conflict occurs because the commit 89e856e124f9("bluetooth/l2cap: sync sock recv cb and release") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/bluetooth/l2cap_sock.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index 13afdc599b58..409475da9283 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1238,6 +1238,10 @@ static void l2cap_sock_kill(struct sock *sk) BT_DBG("sk %p state %s", sk, state_to_string(sk->sk_state)); + /* Sock is dead, so set chan data to NULL, avoid other task use invalid + * sock pointer. + */ + l2cap_pi(sk)->chan->data = NULL; /* Kill poor orphan */ l2cap_chan_put(l2cap_pi(sk)->chan); @@ -1480,9 +1484,21 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan) static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb) { - struct sock *sk = chan->data; + struct sock *sk; int err; + /* To avoid race with sock_release, a chan lock needs to be added here + * to synchronize the sock. + */ + l2cap_chan_hold(chan); + l2cap_chan_lock(chan); + sk = chan->data; + if (!sk) { + l2cap_chan_unlock(chan); + l2cap_chan_put(chan); + return -ENXIO; + } + lock_sock(sk); if (l2cap_pi(sk)->rx_busy_skb) { @@ -1519,6 +1535,8 @@ static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb) done: release_sock(sk); + l2cap_chan_unlock(chan); + l2cap_chan_put(chan); return err; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-42105
by Chen Ridong 02 Aug '24

02 Aug '24

*** BLURB HERE *** Ryusuke Konishi (1): nilfs2: fix inode number range checks fs/nilfs2/nilfs.h | 5 +++-- fs/nilfs2/the_nilfs.c | 6 ++++++ fs/nilfs2/the_nilfs.h | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-42105
by Chen Ridong 02 Aug '24

02 Aug '24

*** BLURB HERE *** Ryusuke Konishi (1): nilfs2: fix inode number range checks fs/nilfs2/nilfs.h | 5 +++-- fs/nilfs2/the_nilfs.c | 6 ++++++ fs/nilfs2/the_nilfs.h | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/1] CVE-2024-42105
by Chen Ridong 02 Aug '24

02 Aug '24

*** BLURB HERE *** Ryusuke Konishi (1): nilfs2: fix inode number range checks fs/nilfs2/nilfs.h | 5 +++-- fs/nilfs2/the_nilfs.c | 6 ++++++ fs/nilfs2/the_nilfs.h | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] smart_grid: introducing rebuild_affinity_domain
by Yipeng Zou 02 Aug '24

02 Aug '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9OJK9 CVE: NA ---------------------------------------- Here are many scenarios we tested with smart_grid, we found that the first domain level is key to the benchmark. The reason is that there are many things such as interrupt affinity, memory affinity factor that can have a big impact on the test. Before this patch, the first domain level is unchangeable after creation. This patch introduce the 'cpu.rebuild_affinity_domain' to dynamically reconfigure all domain levels. Typical use cases: echo $cpu_id > cpu.rebuild_affinity_domain The cpu_id means which cpu we want to set first level. If we set cpu_id = 34, we can see some change like: ---------------- ----------------- | level 0 (0-31) | | level 0 (32-63) | ---------------- ----------------- v v ------------------- ------------------ | level 1 (0-63) | | level 1 (0-63) | ------------------- ------------------ v --> v --------------------- -------------------- | level 2 (0-95) | | level 2 (0-95) | --------------------- -------------------- v v ------------------------ ---------------------- | level 3 (0-127) | | level 3 (0-127) | ------------------------ ---------------------- There are number of constraints on the rebuild feature: 1. Only rebuild domain while auto mode disabled. (cpu.dynamic_affinity_mode == 1) 2. Only rebuild on active and housekeeping cpu. (Offline and isolate CPUs are forbidden) 3. This file is write only. Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/sched/core.c | 13 +++++++++++++ kernel/sched/fair.c | 43 +++++++++++++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 1 + 3 files changed, 57 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 700dbd19eb44..b9b3f536959d 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -11555,6 +11555,15 @@ static int cpu_affinity_stat_show(struct seq_file *sf, void *v) return 0; } + +static int cpu_rebuild_affinity_domain_u64(struct cgroup_subsys_state *css, + struct cftype *cftype, + u64 cpu) +{ + struct task_group *tg = css_tg(css); + + return tg_rebuild_affinity_domains(cpu, tg->auto_affinity); +} #endif /* CONFIG_QOS_SCHED_SMART_GRID */ #ifdef CONFIG_QOS_SCHED @@ -11735,6 +11744,10 @@ static struct cftype cpu_legacy_files[] = { .name = "affinity_stat", .seq_show = cpu_affinity_stat_show, }, + { + .name = "rebuild_affinity_domain", + .write_u64 = cpu_rebuild_affinity_domain_u64, + }, #endif #ifdef CONFIG_CFS_BANDWIDTH { diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 240e315d8e02..e27058ab099d 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7252,6 +7252,49 @@ static void destroy_auto_affinity(struct task_group *tg) kfree(tg->auto_affinity); tg->auto_affinity = NULL; } + +int tg_rebuild_affinity_domains(int cpu, struct auto_affinity *auto_affi) +{ + int ret = 0; + int level = 0; + struct sched_domain *tmp; + + if (unlikely(!auto_affi)) + return -EPERM; + + mutex_lock(&smart_grid_used_mutex); + raw_spin_lock_irq(&auto_affi->lock); + /* Only build domain while auto mode disabled */ + if (auto_affi->mode) { + ret = -EPERM; + goto unlock_all; + } + + /* Only build on active and housekeeping cpu */ + if (!cpu_active(cpu) || !housekeeping_cpu(cpu, HK_TYPE_DOMAIN)) { + ret = -EINVAL; + goto unlock_all; + } + + for_each_domain(cpu, tmp) { + if (!auto_affi->ad.domains[level] || !auto_affi->ad.domains_orig[level]) + continue; + + /* rebuild domain[,_orig] and reset schedstat counter */ + cpumask_copy(auto_affi->ad.domains[level], sched_domain_span(tmp)); + cpumask_copy(auto_affi->ad.domains_orig[level], auto_affi->ad.domains[level]); + __schedstat_set(auto_affi->ad.stay_cnt[level], 0); + level++; + } + + /* trigger to update smart grid zone */ + sched_grid_zone_update(false); + +unlock_all: + raw_spin_unlock_irq(&auto_affi->lock); + mutex_unlock(&smart_grid_used_mutex); + return ret; +} #else static void __maybe_unused destroy_auto_affinity(struct task_group *tg) {} diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 9de2bac6444f..79b93b0a2ef0 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -551,6 +551,7 @@ extern void start_auto_affinity(struct auto_affinity *auto_affi); extern void stop_auto_affinity(struct auto_affinity *auto_affi); extern int init_auto_affinity(struct task_group *tg); extern void tg_update_affinity_domains(int cpu, int online); +extern int tg_rebuild_affinity_domains(int cpu, struct auto_affinity *auto_affi); #else static inline int init_auto_affinity(struct task_group *tg) -- 2.34.1

2 1