ISHACK AI BOT

Ubuntu: (CVE-2023-52483): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: mctp: perform route lookups under a RCU read-side lock Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net's route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer. Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree. The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates. Based on an analysis from Sili Luo <[email protected]>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-15 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-nvidia-6-5 ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52483 CVE - 2023-52483 https://git.kernel.org/linus/5093bbfc10ab6636b32728e35813cbd79feb063c https://www.cve.org/CVERecord?id=CVE-2023-52483

Ubuntu: (CVE-2023-52482): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-15 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-nvidia-6-5 ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52482 CVE - 2023-52482 https://git.kernel.org/linus/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d https://www.cve.org/CVERecord?id=CVE-2023-52482

Ubuntu: (CVE-2023-52477): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-15 ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-nvidia-6-5 ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52477 CVE - 2023-52477 https://git.kernel.org/linus/f74a7afc224acd5e922c7a2e52244d891bbe44ee https://www.cve.org/CVERecord?id=CVE-2023-52477

Ubuntu: (CVE-2023-52479): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-15 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-nvidia-6-5 ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2023-52479 CVE - 2023-52479 https://git.kernel.org/linus/c69813471a1ec081a0b9bf0c6bd7e8afd818afce https://www.cve.org/CVERecord?id=CVE-2023-52479

Ubuntu: (CVE-2023-52481): linux-nvidia-6.5 vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 11/19/2024 Description In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled). Solution(s) ubuntu-upgrade-linux-nvidia-6-5 References https://attackerkb.com/topics/cve-2023-52481 CVE - 2023-52481 https://git.kernel.org/linus/471470bc7052d28ce125901877dd10e4c048e513 https://www.cve.org/CVERecord?id=CVE-2023-52481

Huawei EulerOS: CVE-2023-52478: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/23/2024 Added 07/23/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel:? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel:dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel:kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- Solution(s) huawei-euleros-2_0_sp8-upgrade-bpftool huawei-euleros-2_0_sp8-upgrade-kernel huawei-euleros-2_0_sp8-upgrade-kernel-devel huawei-euleros-2_0_sp8-upgrade-kernel-headers huawei-euleros-2_0_sp8-upgrade-kernel-tools huawei-euleros-2_0_sp8-upgrade-kernel-tools-libs huawei-euleros-2_0_sp8-upgrade-perf huawei-euleros-2_0_sp8-upgrade-python-perf huawei-euleros-2_0_sp8-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52478 CVE - 2023-52478 EulerOS-SA-2024-2476

VMware Photon OS: CVE-2023-52477 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2023-52477 CVE - 2023-52477

Debian: CVE-2021-47020: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: soundwire: stream: fix memory leak in stream config error path When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47020 CVE - 2021-47020

Debian: CVE-2021-47058: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: regmap: set debugfs_name to NULL after it is freed There is a upstream commit cffa4b2122f5("regmap:debugfs: Fix a memory leak when calling regmap_attach_dev") that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() ... regmap_debugfs_init() So, set debugfs_name to NULL after it is freed. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47058 CVE - 2021-47058

Debian: CVE-2021-47056: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [7.180345] Call Trace: [7.182576]mutex_lock+0xc9/0xd0 [7.183257]adf_iov_putmsg+0x118/0x1a0 [intel_qat] [7.183541]adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [7.183834]adf_dev_shutdown+0x172/0x2b0 [intel_qat] [7.184127]adf_probe+0x5e9/0x600 [qat_dh895xccvf] Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47056 CVE - 2021-47056

SUSE: CVE-2024-26458: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 03/27/2024 Added 03/27/2024 Modified 04/09/2024 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. Solution(s) suse-upgrade-krb5 suse-upgrade-krb5-32bit suse-upgrade-krb5-client suse-upgrade-krb5-devel suse-upgrade-krb5-devel-32bit suse-upgrade-krb5-doc suse-upgrade-krb5-plugin-kdb-ldap suse-upgrade-krb5-plugin-preauth-otp suse-upgrade-krb5-plugin-preauth-pkinit suse-upgrade-krb5-plugin-preauth-spake suse-upgrade-krb5-server References https://attackerkb.com/topics/cve-2024-26458 CVE - 2024-26458

Amazon Linux AMI 2: CVE-2023-52477: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 06/11/2024 Added 06/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-4-14-328-248-540 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-199-190-747 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-136-90-144 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2023-52477 AL2/ALAS-2023-2340 AL2/ALASKERNEL-5.10-2023-043 AL2/ALASKERNEL-5.15-2023-029 AL2/ALASKERNEL-5.4-2023-056 CVE - 2023-52477

Amazon Linux AMI 2: CVE-2023-52476: Security patch for kernel (ALASKERNEL-5.15-2023-030) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 06/11/2024 Added 06/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-137-91-144 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2023-52476 AL2/ALASKERNEL-5.15-2023-030 CVE - 2023-52476

SUSE: CVE-2024-26141: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 03/07/2024 Added 03/06/2024 Modified 03/21/2024 Description Rack is a modular Ruby web server interface. Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). The vulnerability is fixed in 3.0.9.1 and 2.2.8.1. Solution(s) suse-upgrade-ruby2-1-rubygem-rack-1_4 suse-upgrade-ruby2-5-rubygem-rack suse-upgrade-ruby2-5-rubygem-rack-doc suse-upgrade-ruby2-5-rubygem-rack-testsuite References https://attackerkb.com/topics/cve-2024-26141 CVE - 2024-26141

SUSE: CVE-2024-26462: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 03/27/2024 Added 03/27/2024 Modified 03/27/2024 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c. Solution(s) suse-upgrade-krb5 suse-upgrade-krb5-32bit suse-upgrade-krb5-client suse-upgrade-krb5-devel suse-upgrade-krb5-devel-32bit suse-upgrade-krb5-plugin-kdb-ldap suse-upgrade-krb5-plugin-preauth-otp suse-upgrade-krb5-plugin-preauth-pkinit suse-upgrade-krb5-plugin-preauth-spake suse-upgrade-krb5-server References https://attackerkb.com/topics/cve-2024-26462 CVE - 2024-26462

Red Hat: CVE-2023-52478: kernel: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:N/A:C) Published 02/29/2024 Created 09/26/2024 Added 09/25/2024 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel:? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel:dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel:kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2023-52478 RHSA-2024:7000 RHSA-2024:7001

Alma Linux: CVE-2023-51779: Moderate: kernel security, bug fix, and enhancement update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/01/2024 Added 05/31/2024 Modified 11/04/2024 Description bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free because of a bt_sock_ioctl race condition. Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-64k alma-upgrade-kernel-64k-core alma-upgrade-kernel-64k-debug alma-upgrade-kernel-64k-debug-core alma-upgrade-kernel-64k-debug-devel alma-upgrade-kernel-64k-debug-devel-matched alma-upgrade-kernel-64k-debug-modules alma-upgrade-kernel-64k-debug-modules-core alma-upgrade-kernel-64k-debug-modules-extra alma-upgrade-kernel-64k-devel alma-upgrade-kernel-64k-devel-matched alma-upgrade-kernel-64k-modules alma-upgrade-kernel-64k-modules-core alma-upgrade-kernel-64k-modules-extra alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-devel-matched alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-core alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-debug-uki-virt alma-upgrade-kernel-devel alma-upgrade-kernel-devel-matched alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-core alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-core alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-core alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-uki-virt alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-devel-matched alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-core alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-libperf alma-upgrade-perf alma-upgrade-python3-perf alma-upgrade-rtla alma-upgrade-rv References https://attackerkb.com/topics/cve-2023-51779 CVE - 2023-51779 https://errata.almalinux.org/8/ALSA-2024-2950.html https://errata.almalinux.org/8/ALSA-2024-3138.html https://errata.almalinux.org/9/ALSA-2024-2394.html

Rocky Linux: CVE-2023-51779: kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 06/17/2024 Added 06/17/2024 Modified 11/18/2024 Description bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free because of a bt_sock_ioctl race condition. Solution(s) rocky-upgrade-bpftool rocky-upgrade-bpftool-debuginfo rocky-upgrade-kernel rocky-upgrade-kernel-core rocky-upgrade-kernel-cross-headers rocky-upgrade-kernel-debug rocky-upgrade-kernel-debug-core rocky-upgrade-kernel-debug-debuginfo rocky-upgrade-kernel-debug-devel rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-extra rocky-upgrade-kernel-rt rocky-upgrade-kernel-rt-core rocky-upgrade-kernel-rt-debug rocky-upgrade-kernel-rt-debug-core rocky-upgrade-kernel-rt-debug-debuginfo rocky-upgrade-kernel-rt-debug-devel rocky-upgrade-kernel-rt-debug-kvm rocky-upgrade-kernel-rt-debug-modules rocky-upgrade-kernel-rt-debug-modules-extra rocky-upgrade-kernel-rt-debuginfo rocky-upgrade-kernel-rt-debuginfo-common-x86_64 rocky-upgrade-kernel-rt-devel rocky-upgrade-kernel-rt-kvm rocky-upgrade-kernel-rt-modules rocky-upgrade-kernel-rt-modules-extra rocky-upgrade-kernel-tools rocky-upgrade-kernel-tools-debuginfo rocky-upgrade-kernel-tools-libs rocky-upgrade-kernel-tools-libs-devel rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2023-51779 CVE - 2023-51779 https://errata.rockylinux.org/RLSA-2024:2950 https://errata.rockylinux.org/RLSA-2024:3138

Huawei EulerOS: CVE-2023-52477: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 07/23/2024 Added 07/23/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Solution(s) huawei-euleros-2_0_sp8-upgrade-bpftool huawei-euleros-2_0_sp8-upgrade-kernel huawei-euleros-2_0_sp8-upgrade-kernel-devel huawei-euleros-2_0_sp8-upgrade-kernel-headers huawei-euleros-2_0_sp8-upgrade-kernel-tools huawei-euleros-2_0_sp8-upgrade-kernel-tools-libs huawei-euleros-2_0_sp8-upgrade-perf huawei-euleros-2_0_sp8-upgrade-python-perf huawei-euleros-2_0_sp8-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52477 CVE - 2023-52477 EulerOS-SA-2024-2476

Alma Linux: CVE-2023-52478: Important: kernel security update (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 09/27/2024 Added 09/26/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel:? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel:? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel:dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel:kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- Solution(s) alma-upgrade-bpftool alma-upgrade-kernel alma-upgrade-kernel-abi-stablelists alma-upgrade-kernel-core alma-upgrade-kernel-cross-headers alma-upgrade-kernel-debug alma-upgrade-kernel-debug-core alma-upgrade-kernel-debug-devel alma-upgrade-kernel-debug-modules alma-upgrade-kernel-debug-modules-extra alma-upgrade-kernel-devel alma-upgrade-kernel-doc alma-upgrade-kernel-headers alma-upgrade-kernel-modules alma-upgrade-kernel-modules-extra alma-upgrade-kernel-rt alma-upgrade-kernel-rt-core alma-upgrade-kernel-rt-debug alma-upgrade-kernel-rt-debug-core alma-upgrade-kernel-rt-debug-devel alma-upgrade-kernel-rt-debug-kvm alma-upgrade-kernel-rt-debug-modules alma-upgrade-kernel-rt-debug-modules-extra alma-upgrade-kernel-rt-devel alma-upgrade-kernel-rt-kvm alma-upgrade-kernel-rt-modules alma-upgrade-kernel-rt-modules-extra alma-upgrade-kernel-tools alma-upgrade-kernel-tools-libs alma-upgrade-kernel-tools-libs-devel alma-upgrade-kernel-zfcpdump alma-upgrade-kernel-zfcpdump-core alma-upgrade-kernel-zfcpdump-devel alma-upgrade-kernel-zfcpdump-modules alma-upgrade-kernel-zfcpdump-modules-extra alma-upgrade-perf alma-upgrade-python3-perf References https://attackerkb.com/topics/cve-2023-52478 CVE - 2023-52478 https://errata.almalinux.org/8/ALSA-2024-7000.html https://errata.almalinux.org/8/ALSA-2024-7001.html

Ubuntu: (CVE-2021-47060): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus.If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus.In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47060 CVE - 2021-47060 https://git.kernel.org/linus/5d3c4c79384af06e3c8e25b7770b6247496b4417 https://www.cve.org/CVERecord?id=CVE-2021-47060

Ubuntu: (CVE-2021-47054): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: bus: qcom: Put child node before return Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47054 CVE - 2021-47054 https://git.kernel.org/linus/ac6ad7c2a862d682bb584a4bc904d89fa7721af8 https://www.cve.org/CVERecord?id=CVE-2021-47054

Ubuntu: USN-7148-1 (CVE-2021-47055): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: mtd: require write permissions for locking and badblock ioctls MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. Solution(s) ubuntu-upgrade-linux-image-4-4-0-1138-aws ubuntu-upgrade-linux-image-4-4-0-1139-kvm ubuntu-upgrade-linux-image-4-4-0-1176-aws ubuntu-upgrade-linux-image-4-4-0-261-generic ubuntu-upgrade-linux-image-4-4-0-261-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-lts-xenial ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-lts-xenial ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-lts-xenial References https://attackerkb.com/topics/cve-2021-47055 CVE - 2021-47055 USN-7148-1 https://git.kernel.org/linus/1e97743fd180981bef5f01402342bb54bf1c6366 https://www.cve.org/CVERecord?id=CVE-2021-47055

Ubuntu: (CVE-2021-47056): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/29/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [7.180345] Call Trace: [7.182576]mutex_lock+0xc9/0xd0 [7.183257]adf_iov_putmsg+0x118/0x1a0 [intel_qat] [7.183541]adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [7.183834]adf_dev_shutdown+0x172/0x2b0 [intel_qat] [7.184127]adf_probe+0x5e9/0x600 [qat_dh895xccvf] Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47056 CVE - 2021-47056 https://git.kernel.org/linus/8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446 https://www.cve.org/CVERecord?id=CVE-2021-47056

Ubuntu: (Multiple Advisories) (CVE-2021-47063): Linux kernel vulnerabilities Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/29/2024 Created 07/04/2024 Added 07/04/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Solution(s) ubuntu-upgrade-linux-image-4-15-0-1132-oracle ubuntu-upgrade-linux-image-4-15-0-1153-kvm ubuntu-upgrade-linux-image-4-15-0-1163-gcp ubuntu-upgrade-linux-image-4-15-0-1169-aws ubuntu-upgrade-linux-image-4-15-0-1178-azure ubuntu-upgrade-linux-image-4-15-0-226-generic ubuntu-upgrade-linux-image-4-15-0-226-lowlatency ubuntu-upgrade-linux-image-5-4-0-1038-iot ubuntu-upgrade-linux-image-5-4-0-1045-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1073-ibm ubuntu-upgrade-linux-image-5-4-0-1086-bluefield ubuntu-upgrade-linux-image-5-4-0-1093-gkeop ubuntu-upgrade-linux-image-5-4-0-1110-raspi ubuntu-upgrade-linux-image-5-4-0-1114-kvm ubuntu-upgrade-linux-image-5-4-0-1125-oracle ubuntu-upgrade-linux-image-5-4-0-1126-aws ubuntu-upgrade-linux-image-5-4-0-1130-gcp ubuntu-upgrade-linux-image-5-4-0-1131-azure ubuntu-upgrade-linux-image-5-4-0-186-generic ubuntu-upgrade-linux-image-5-4-0-186-generic-lpae ubuntu-upgrade-linux-image-5-4-0-186-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-hwe ubuntu-upgrade-linux-image-aws-lts-18-04 ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-lts-18-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-18-04 ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-hwe-16-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-hwe-16-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-18-04 ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-16-04 ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2021-47063 CVE - 2021-47063 USN-6831-1 USN-6866-1 USN-6866-2 USN-6866-3 USN-6867-1