Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
mon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed"). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/22e19c8c5f6b709f4ae40227392a30d57bac187d - https://git.kernel.org/stable/c/95036d4c01167568166108d42c2b0e9f8dbd7d2b - https://git.kernel.org/stable/c/eb0e0eca0eab93f310c6c37b8564049366704691 - https://git.kernel.org/stable/c/1c5673a2c8926adbb61f340c779b28e18188a8cd - https://git.kernel.org/stable/c/f8805b12f477bd964e2820a87921c7b58cc2dee3 - https://git.kernel.org/stable/c/21f1435b1e6b012a07c42f36b206d2b66fc8f13b
CVE ID: CVE-2024-58087 State: PUBLISHED Published: 2025-03-12T07:28:09.114Z Last Updated: 2025-10-01T19:36:35.134Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue from session lookup and expire Increment the session reference count within the lock for lookup to avoid racy issue with session expire. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2107ab40629aeabbec369cf34b8cf0f288c3eb1b - https://git.kernel.org/stable/c/37a0e2b362b3150317fb6e2139de67b1e29ae5ff - https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd - https://git.kernel.org/s
2139de67b1e29ae5ff - https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd - https://git.kernel.org/stable/c/a39e31e22a535d47b14656a7d6a893c7f6cf758c - https://git.kernel.org/stable/c/b95629435b84b9ecc0c765995204a4d8a913ed52 - https://www.zerodayinitiative.com/advisories/ZDI-25-100/
CVE ID: CVE-2024-58088 State: PUBLISHED Published: 2025-03-12T09:41:58.986Z Last Updated: 2025-10-01T19:36:35.008Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock when freeing cgroup storage The following commit bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]") first introduced deadlock prevention for fentry/fexit programs attaching on bpf_task_storage helpers. That commit also employed the logic in map free path in its v6 version. Later bpf_cgrp_storage was first introduced in c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs") which faces
irst introduced in c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs") which faces the same issue as bpf_task_storage, instead of its busy counter, NULL was passed to bpf_local_storage_map_free() which opened a window to cause deadlock: <TASK> (acquiring local_storage->lock) _raw_spin_lock_irqsave+0x3d/0x50 bpf_local_storage_update+0xd1/0x460 bpf_cgrp_storage_get+0x109/0x130 bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170 ? __bpf_prog_enter_recur+0x16/0x80 bpf_trampoline_6442485186+0x43/0xa4 cgroup_storage_ptr+0x9/0x20 (holding local_storage->lock) bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160 bpf_selem_unlink_storage+0x6f/0x110 bpf_local_storag
rage->lock) bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160 bpf_selem_unlink_storage+0x6f/0x110 bpf_local_storage_map_free+0xa2/0x110 bpf_map_free_deferred+0x5b/0x90 process_one_work+0x17c/0x390 worker_thread+0x251/0x360 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Progs: - A: SEC("fentry/cgroup_storage_ptr") - cgid (BPF_MAP_TYPE_HASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get
above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpf_cgroup_from_id(). This trusted pointer can then be passed to bpf_cgrp_storage_get() to finally trigger the deadlock issue. - B: SEC("tp_btf/sys_enter") - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpf_cgrp_storage_get() for as many userspace tasks as possible. Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; } Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking. Additional Analyst N
s busy counter to the free procedure so it can be properly incremented before storage/smap locking. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6ecb9fa14eec5f15d97c84c36896871335f6ddfb - https://git.kernel.org/stable/c/fac674d2bd68f3479f27328626b42d1eebd11fef - https://git.kernel.org/stable/c/fcec95b4ab3e7bc6b2f36e5d59f7e24104ea87f7 - https://git.kernel.org/stable/c/c78f4afbd962f43a3989f45f3ca04300252b19b5
CVE ID: CVE-2024-58089 State: PUBLISHED Published: 2025-03-12T09:41:59.709Z Last Updated: 2025-10-01T19:36:34.870Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double accounting race when btrfs_run_delalloc_range() failed [BUG] When running btrfs with block size (4K) smaller than page size (64K, aarch64), there is a very high chance to crash the kernel at generic/750, with the following messages: (before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: inter
te for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Ta
rdered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 f
x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino
fset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : wo
s-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b [CAUSE] The above warning
fff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b [CAUSE] The above warning is triggered immediately after the delalloc range failure, this happens in the following sequence: - Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size) - Enter extent_writepage() for page 1536K - Enter run_delalloc_nocow() with locke ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/21333148b5c9e52f41fafcedec3810b56a5e0e40 - https://git.kernel.org/stable/c/0283ee1912c8e243c931f4ee5b3672e954fe0384 - https://git.ker
52f41fafcedec3810b56a5e0e40 - https://git.kernel.org/stable/c/0283ee1912c8e243c931f4ee5b3672e954fe0384 - https://git.kernel.org/stable/c/72dad8e377afa50435940adfb697e070d3556670
CVE ID: CVE-2024-58090 State: PUBLISHED Published: 2025-03-27T14:57:02.886Z Last Updated: 2025-11-03T19:34:24.381Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/core: Prevent rescheduling when interrupts are disabled David reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 The corresponding interrupt flag trace: hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90 hardirqs last
g interrupt flag trace: hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90 That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate
+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some
ontext. The scheduler enables interrupts after context switching, which causes the above warning at the end. Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time. The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account. Cure the problem by adding a corresponding check into cond_resched(). Additional Analyst Notes: - CVE Program Co
ccount. Cure the problem by adding a corresponding check into cond_resched(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/321794b75ac968f0bb6b9c913581949452a8d992 - https://git.kernel.org/stable/c/1651f5731b378616565534eb9cda30e258cebebc - https://git.kernel.org/stable/c/288fdb8dcb71ec77b76ab8b8a06bc10f595ea504 - https://git.kernel.org/stable/c/84586322e010164eedddfcd0a0894206ae7d9317 - https://git.kernel.org/stable/c/68786ab0935ccd5721283b7eb7f4d2f2942c7a52 - https://git.kernel.org/stable/c/0362847c520747b44b574d363705d8af0621727a - https://git.kernel.org/stable/c/b927c8539f692fb1f9c2f42e6c8ea2d94956f921 - https://git.kernel.org/stable/c/
af0621727a - https://git.kernel.org/stable/c/b927c8539f692fb1f9c2f42e6c8ea2d94956f921 - https://git.kernel.org/stable/c/82c387ef7568c0d96a918a5a78d9cad6256cfa15
CVE ID: CVE-2024-58091 State: PUBLISHED Published: 2025-03-27T14:57:03.560Z Last Updated: 2025-07-06T09:08:48.847Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Add shadow buffering for deferred I/O DMA areas are not necessarily backed by struct page, so we cannot rely on it for deferred I/O. Allocate a shadow buffer for drivers that require deferred I/O and use it as framebuffer memory. Fixes driver errors about being "Unable to handle kernel NULL pointer dereference at virtual address" or "Unable to handle kernel paging request at virtual address". The patch splits drm_fbdev_dma_driver_fbdev_probe() in an init
able to handle kernel paging request at virtual address". The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial allocation, which creates the DMA-backed buffer object, and a tail that sets up the fbdev data structures. There is a tail function for direct memory mappings and a tail function for deferred I/O with the shadow buffer. It is no longer possible to use deferred I/O without shadow buffer. It can be re-added if there exists a reliably test for usable struct page in the allocated DMA-backed buffer object. References: - https://git.kernel.org/stable/c/0d087de947babf7ed70029d042abcc6ed06ff415 - https://git.kernel.org/stable/c/cdc581169942de3b9e2648cfbd98c5ff9111c2c8 - https:/
de947babf7ed70029d042abcc6ed06ff415 - https://git.kernel.org/stable/c/cdc581169942de3b9e2648cfbd98c5ff9111c2c8 - https://git.kernel.org/stable/c/3603996432997f7c88da37a97062a46cda01ac9d
CVE ID: CVE-2024-58092 State: PUBLISHED Published: 2025-04-16T10:24:53.056Z Last Updated: 2025-05-04T10:09:54.155Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: fix legacy client tracking initialization Get rid of the nfsd4_legacy_tracking_ops->init() call in check_for_legacy_methods(). That will be handled in the caller (nfsd4_client_tracking_init()). Otherwise, we'll wind up calling nfsd4_legacy_tracking_ops->init() twice, and the second time we'll trigger the BUG_ON() in nfsd4_init_recdir(). References: - https://git.kernel.org/stable/c/95407304253a4bf03494d921c6913e220c26cc63 - https://git.kernel.org/stable/c/cdd6608
es: - https://git.kernel.org/stable/c/95407304253a4bf03494d921c6913e220c26cc63 - https://git.kernel.org/stable/c/cdd66082b227eb695cbf54b7c121ea032e869981 - https://git.kernel.org/stable/c/de71d4e211eddb670b285a0ea477a299601ce1ca
CVE ID: CVE-2024-58093 State: PUBLISHED Published: 2025-04-16T14:11:42.682Z Last Updated: 2025-05-26T05:16:33.817Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix link state exit during switch upstream function removal Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function r
wnstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. [k
e exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. [kwilczynski: commit log] References: - https://git.kernel.org/stable/c/cbf937dcadfd571a434f8074d057b32cd14fbea5
CVE ID: CVE-2024-58094 State: PUBLISHED Published: 2025-04-16T14:11:43.298Z Last Updated: 2025-05-26T05:16:35.249Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for "read-only" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no
NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the "COMMIT_WMAP" flag, preventing modifications in "read-only" mode. References: - https://git.kernel.org/stable/c/f605bc3e162f5c6faa9bd3602ce496053d06a4bb - https://git.kernel.org/stable/c/b5799dd77054c1ec49b0088b006c9908e256843b
CVE ID: CVE-2024-58095 State: PUBLISHED Published: 2025-04-16T14:11:43.934Z Last Updated: 2025-05-26T05:16:36.603Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_
s/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299 References: - https://git.kernel.org/stable/c/15469c408af2d7a52fb186a92f2f091b0f13b1fb - https://git.kernel.org/stable/c/0176e69743ecc02961f2ae1ea42439cd2bf9ed58
CVE ID: CVE-2024-58096 State: PUBLISHED Published: 2025-04-16T14:11:44.587Z Last Updated: 2025-05-26T05:16:37.832Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon
_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_proce
vent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 References: - https://git.kernel.org/stable/c/b85758e76b6452740fc2a08ced6759af64c0d59a - https://git.kernel.org/stable/c/63b7af49496d0e32f7a748b6af3361ec138b1bd3
CVE ID: CVE-2024-58097 State: PUBLISHED Published: 2025-04-16T14:11:45.330Z Last Updated: 2025-10-01T17:05:56.577Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix RCU stall while reaping monitor destination ring While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_
processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b4991fc4174
_SILICONZ-1 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b4991fc41745645f8050506f5a8578bd11e6b378 - https://git.kernel.org/stable/c/16c6c35c03ea73054a1f6d3302a4ce4a331b427d
CVE ID: CVE-2024-58098 State: PUBLISHED Published: 2025-05-05T14:53:32.417Z Last Updated: 2025-05-09T08:06:08.048Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: track changes_pkt_data property for global functions When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) re