Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-52477 State: PUBLISHED Published: 2024-02-29T05:43:10.088Z Last Updated: 2025-05-04T07:37:31.719Z Vendors: Linux Products: Linux 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:
ULL 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
010246 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 ? kt
5b7/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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81 - https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d - https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3 - https://git.ke
453e31b7421c1c17ca2fb9ed613d - https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3 - https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c - https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b - https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81 - https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289 - https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee
CVE ID: CVE-2023-52478 State: PUBLISHED Published: 2024-02-29T05:43:10.698Z Last Updated: 2025-05-04T07:37:33.135Z Vendors: Linux Products: Linux 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 workqueu
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 tak
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_regi
ry.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->batter
.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
ter 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_
G: 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--- Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f31
m Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 - https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c - https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b - https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1 - https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528 - https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d - https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e - https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452
CVE ID: CVE-2023-52479 State: PUBLISHED Published: 2024-02-29T05:43:11.373Z Last Updated: 2025-05-04T07:37:34.477Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd - https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930 - https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9 - https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce
CVE ID: CVE-2023-52480 State: PUBLISHED Published: 2024-02-29T05:43:12.019Z Last Updated: 2025-05-04T07:37:35.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kern
pire_session. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f - https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b - https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be - https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f
CVE ID: CVE-2023-52481 State: PUBLISHED Published: 2024-02-29T05:43:12.630Z Last Updated: 2025-05-04T07:37:36.749Z Vendors: Linux Products: Linux 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 T
slation (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). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c - https://git.kernel.org/stable/c/32b0a4ffcaea44a
tps://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c - https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25 - https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513
CVE ID: CVE-2023-52482 State: PUBLISHED Published: 2024-02-29T05:43:13.242Z Last Updated: 2025-05-21T08:49:44.230Z Vendors: Linux Products: Linux 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d - https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37 - https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96
e/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37 - https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96 - https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4 - https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d
CVE ID: CVE-2023-52483 State: PUBLISHED Published: 2024-02-29T05:43:13.861Z Last Updated: 2025-05-04T07:37:39.148Z Vendors: Linux Products: Linux 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 parall
er. 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 <rootlab@huawei.com>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67 - https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a - https://git.kernel.org/stable/c/2405f64a95a7a094eb
://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a - https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4 - https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c
CVE ID: CVE-2023-52484 State: PUBLISHED Published: 2024-02-29T05:43:14.502Z Last Updated: 2025-05-04T07:37:40.539Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000
cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 00000000800000
000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 --
nstprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_a
lb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b - https://git.kernel.or
ontainer: References: - https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b - https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264 - https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429 - https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6
CVE ID: CVE-2023-52485 State: PUBLISHED Published: 2024-02-29T14:57:51.179Z Last Updated: 2025-07-11T17:19:29.282Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before sending a command [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we're done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot i
mission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009 - https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39
CVE ID: CVE-2023-52486 State: PUBLISHED Published: 2024-02-29T15:52:06.888Z Last Updated: 2025-05-04T07:37:42.728Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually
ceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://g
ck down the culprit. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229 - https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7 - https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105 - https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551 - https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0 - https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c - https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a - https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76
org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a - https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
CVE ID: CVE-2023-52487 State: PUBLISHED Published: 2024-02-29T15:52:07.507Z Last Updated: 2025-05-04T07:37:43.887Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix peer flow lists handling The cited change refactored mlx5e_tc_del_fdb_peer_flow() to only clear DUP flag when list of peer flows has become empty. However, if any concurrent user holds a reference to a peer flow (for example, the neighbor update workqueue task is updating peer flow's parent encap entry concurrently), then the flow will not be removed from the peer list and, consecutively, DUP flag will remain set. Since mlx5e_tc_del_fdb_peers_flow() call
not be removed from the peer list and, consecutively, DUP flag will remain set. Since mlx5e_tc_del_fdb_peers_flow() calls mlx5e_tc_del_fdb_peer_flow() for every possible peer index the algorithm will try to remove the flow from eswitch instances that it has never peered with causing either NULL pointer dereference when trying to remove the flow peer list head of peer_index that was never initialized or a warning if the list debug config is enabled[0]. Fix the issue by always removing the peer flow from the list even when not releasing the last reference to it. [0]: [ 3102.985806] ------------[ cut here ]------------ [ 3102.986223] list_del corruption, ffff888139110698->next is NULL [ 3102.98
85806] ------------[ cut here ]------------ [ 3102.986223] list_del corruption, ffff888139110698->next is NULL [ 3102.986757] WARNING: CPU: 2 PID: 22109 at lib/list_debug.c:53 __list_del_entry_valid_or_report+0x4f/0xc0 [ 3102.987561] Modules linked in: act_ct nf_flow_table bonding act_tunnel_key act_mirred act_skbedit vxlan cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa openvswitch nsh xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcg ss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uver