Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 - https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b
CVE ID: CVE-2024-26758 State: PUBLISHED Published: 2024-04-03T17:00:42.448Z Last Updated: 2025-05-04T08:55:50.864Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_th
: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring
MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0 - https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757
CVE ID: CVE-2024-26759 State: PUBLISHED Published: 2024-04-03T17:00:43.288Z Last Updated: 2025-05-04T08:55:52.045Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, ca
e possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> ... set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but
e to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait s
nt any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it's a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]: With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.
th latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Polulating 32MB of memory region... Keep swapping out... Starting round 0... Spawning 65536 workers... 32746 workers spawned, wait for done... Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with
mall swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [kasong@tencent.com: v4] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://g
ong@tencent.com: v4] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95 - https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a - https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d - https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458
CVE ID: CVE-2024-26760 State: PUBLISHED Published: 2024-04-03T17:00:44.230Z Last Updated: 2025-05-04T08:55:53.415Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free(). Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6
Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231 - https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921 - https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec - https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804
CVE ID: CVE-2024-26761 State: PUBLISHED Published: 2024-04-03T17:00:44.934Z Last Updated: 2025-05-04T08:55:54.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL hos
cked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder's CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on pa
only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/031217128990d7f0ab8c46db1afb3cf1e075fd29 - https://git.kernel.org/stable/c/2cc1a530ab31c65b52daf3cb5d0883c8b614ea69 - https://git.kernel.org/stable/c/3a3181a71935774bda2398451256d7441426420b - https://git.kernel.org/stable/c/0cab687205986491302cd2e440ef1d253031c221
CVE ID: CVE-2024-26762 State: PUBLISHED Published: 2024-04-03T17:00:45.655Z Last Updated: 2025-05-04T08:55:56.122Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Skip to handle RAS errors if CXL.mem device is detached The PCI AER model is an awkward fit for CXL error handling. While the expectation is that a PCI device can escalate to link reset to recover from an AER event, the same reset on CXL amounts to a surprise memory hotplug of massive amounts of memory. At present, the CXL error handler attempts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values.
pts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values. This results in a "hopeful" attempt to unplug the memory, but there is no guarantee that will succeed. A subsequent AER notification after the memdev unbind event can no longer assume the registers are mapped. Check for memdev bind before reaping status register values to avoid crashes of the form: BUG: unable to handle page fault for address: ffa00000195e9100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? ke
0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x113/0x170 ? asm_exc_page_fault+0x26/0x30 ? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might need to be replaced with a new PCI_ERS_RESULT_PANIC. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: -
th a new PCI_ERS_RESULT_PANIC. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/21e5e84f3f63fdf44e49642a6e45cd895e921a84 - https://git.kernel.org/stable/c/eef5c7b28dbecd6b141987a96db6c54e49828102
CVE ID: CVE-2024-26763 State: PUBLISHED Published: 2024-04-03T17:00:46.308Z Last Updated: 2025-05-04T08:55:57.430Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://
vent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e - https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa - https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90 - https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529 - https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6 - https://git.kernel.org/stable/c/64ba01a36598075573297
git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6 - https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75 - https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857 - https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7
CVE ID: CVE-2024-26764 State: PUBLISHED Published: 2024-04-03T17:00:46.962Z Last Updated: 2025-05-04T08:55:58.706Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb
118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f - https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942 - https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f - https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f3
able/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f - https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353 - https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487 - https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7 - https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6 - https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760
CVE ID: CVE-2024-26765 State: PUBLISHED Published: 2024-04-03T17:00:47.888Z Last Updated: 2025-05-04T08:56:00.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 9
0000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334
fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e
38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8
[<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58 Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53 - htt
r: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53 - https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464 - https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f - https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a
CVE ID: CVE-2024-26766 State: PUBLISHED Published: 2024-04-03T17:00:48.642Z Last Updated: 2025-05-04T12:54:42.053Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib
}, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea
tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the ma
scs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc1100c49790 - https://git.kernel.org/stable/c/5833024a9856f454a964a198c63a57e59e07baf5 - https://git.kernel.org/stable/c/3f38d22e645e2e994979426ea5a35186102ff3c2 - https://git.kernel.org/stable/c/47ae64df23ed1318e27bd9844e135a5e1c0e6e39 - https://git.kernel.org/stable/c/52dc9a7a573dbf778625a0efca0fca55489f084b - https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a - https://git.kernel.org/
0efca0fca55489f084b - https://git.kernel.org/stable/c/a2fef1d81becf4ff60e1a249477464eae3c3bc2a - https://git.kernel.org/stable/c/9034a1bec35e9f725315a3bb6002ef39666114d9 - https://git.kernel.org/stable/c/e6f57c6881916df39db7d95981a8ad2b9c3458d6
CVE ID: CVE-2024-26767 State: PUBLISHED Published: 2024-04-03T17:00:49.315Z Last Updated: 2025-11-03T19:29:33.118Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/070fda699dfdce560755379bc428d9edada7a54e - https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375 - https://git.kernel.org/s
9bc428d9edada7a54e - https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375 - https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7 - https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738