Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-50269 State: PUBLISHED Published: 2024-11-19T01:30:06.910Z Last Updated: 2025-11-03T22:27:49.620Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_m
iver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/721ddad945596220c123eb6f7126729fe277ee4f - https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1 - https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8 - https://git.kernel
e16c3eed15e858fd5de44de1 - https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8 - https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522bf377dd9 - https://git.kernel.org/stable/c/ccd811c304d2ee56189bfbc49302cb3c44361893 - https://git.kernel.org/stable/c/8a30da5aa9609663b3e05bcc91a916537f66a4cd - https://git.kernel.org/stable/c/b08baa75b989cf779cbfa0969681f8ba2dc46569 - https://git.kernel.org/stable/c/498dbd9aea205db9da674994b74c7bf8e18448bd
CVE ID: CVE-2024-50270 State: PUBLISHED Published: 2024-11-19T01:30:08.406Z Last Updated: 2025-10-01T20:17:23.353Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current sc
to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2d339a1f0f16ff5dea58e612ff336f0be0d041e9 - https://git.kernel.org/stable/c/4401e9d10ab0281a520b9f8c220f30f60b5c248f
CVE ID: CVE-2024-50271 State: PUBLISHED Published: 2024-11-19T01:30:09.788Z Last Updated: 2025-11-03T22:27:51.070Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal deliv
d and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior. Additional Analyst
ip the comparison to max there if override_rlimit is set. This effectively restores the old behavior. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1 - https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7 - https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40 - https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed
CVE ID: CVE-2024-50272 State: PUBLISHED Published: 2024-11-19T01:30:11.194Z Last Updated: 2025-11-03T22:27:52.514Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6cc52
pback NFS mounts. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6cc52df69e8464811f9f6fc12f7aaa78451eb0b8 - https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b - https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235 - https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826 - https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca502fe4ee
CVE ID: CVE-2024-50273 State: PUBLISHED Published: 2024-11-19T01:30:12.589Z Last Updated: 2025-11-03T22:27:54.002Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which c
t to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting
G_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d - https://git.kernel.org/stable/c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb - https://git.kernel.org/stable/c/bf0b0c6d159767c0d1c21f793950d78486690ee0 - https://git.kernel.org/stable/c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851 - https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6 - https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e9993
ble/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6 - https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e99931 - https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a19357a92 - https://git.kernel.org/stable/c/c9a75ec45f1111ef530ab186c2a7684d0a0c9245
CVE ID: CVE-2024-50274 State: PUBLISHED Published: 2024-11-19T01:30:13.973Z Last Updated: 2025-10-01T20:17:22.893Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it,
f the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fa4d906ad0fb63a980a1d586a061c78ea1a345ba - https://git.kernel.org/stable/c/81d2fb4c7c18a3b36ba3e00b9d5b753107472d75
CVE ID: CVE-2024-50275 State: PUBLISHED Published: 2024-11-19T01:30:15.293Z Last Updated: 2025-11-03T20:44:51.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN
from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled |
void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cp
ut_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Additional Analyst Notes: - CV
FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/51d3d80a6dc314982a9a0aeb0961085922a1aa15 - https://git.kernel.org/stable/c/de529504b3274d57caf8f66800b714b0d3ee235a - https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7 - https://git.kernel.org/stable/c/fa9ce027b3ce37a2bb173bf2553b5caa438fd8c9 - https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a6052315552c0483d18
CVE ID: CVE-2024-50276 State: PUBLISHED Published: 2024-11-19T01:30:16.647Z Last Updated: 2025-11-03T22:27:55.487Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: c
al error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024
00000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660) Additional An
32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2cf0e77f5a0aa1ff336aa71743eda55c73902187 - https://git.kernel.org/stable/c/1325e838089da25217f4b403318a270fcdf88f34 - https://git.kernel.org/stable/c/91c9daa21f3ff8668f9e1d6c860024ce7ad64137 - https://git.kernel.org/stable/c/1f26339b2ed63d1e8e18a18674fb73a392f3660e
CVE ID: CVE-2024-50277 State: PUBLISHED Published: 2024-11-19T01:30:17.994Z Last Updated: 2025-10-01T20:17:22.631Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement "md->disk->private_data = NULL;". Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829 - https://git.kernel.org/stable/c/fed13a5478680614ba97fc87e71f1
el.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829 - https://git.kernel.org/stable/c/fed13a5478680614ba97fc87e71f16e2e197912e
CVE ID: CVE-2024-50278 State: PUBLISHED Published: 2024-11-19T01:30:19.352Z Last Updated: 2025-11-03T22:27:56.948Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare
he check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough
load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state ar
virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d - https
- CVE Program Container: References: - https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d - https://git.kernel.org/stable/c/2222b0929d00e2d13732b799b63be391b5de4492 - https://git.kernel.org/stable/c/483b7261b35a9d369082ab298a6670912243f0be - https://git.kernel.org/stable/c/fdef3b94dfebd57e3077a578b6e309a2bb6fa688 - https://git.kernel.org/stable/c/c52ec00cb2f9bebfada22edcc0db385b910a1cdb - https://git.kernel.org/stable/c/036dd6e3d2638103e0092864577ea1d091466b86 - https://git.kernel.org/stable/c/13ed3624c6ef283acefa4cc42cc8ae54fd4391a4 - https://git.kernel.org/stable/c/c0ade5d98979585d4f5a93e4514c2e9a65afa08d
CVE ID: CVE-2024-50279 State: PUBLISHED Published: 2024-11-19T01:30:20.712Z Last Updated: 2025-11-03T22:27:58.416Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 5242
192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f
ache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-inc
f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4 - https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf - https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818 - https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f - https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334 - https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d - https://git.kernel.org/stable/
23a0d4af1334 - https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d - https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c - https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910
CVE ID: CVE-2024-50280 State: PUBLISHED Published: 2024-11-19T01:30:21.999Z Last Updated: 2025-11-03T22:27:59.871Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0