Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-57934 State: PUBLISHED Published: 2025-01-21T12:01:30.537Z Last Updated: 2025-10-01T19:57:14.140Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fgraph: Add READ_ONCE() when accessing fgraph_array[] In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[] elements, which are fgraph_ops. The loop checks if an element is a fgraph_stub to prevent using a fgraph_stub afterward. However, if the compiler reloads fgraph_array[] after this check, it might race with an update to fgraph_array[] that introduces a fgraph_stub. This could result in the stub being processed, but the stub contains a null "func
array[] that introduces a fgraph_stub. This could result in the stub being processed, but the stub contains a null "func_hash" field, leading to a NULL pointer dereference. To ensure that the gops compared against the fgraph_stub matches the gops processed later, add a READ_ONCE(). A similar patch appears in commit 63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]"). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b68b2a3fbacc7be720ef589d489bcacdd05c6d38 - https://git.kernel.org/stable/c/d65474033740ded0a4fe9a097fce72328655b41d
CVE ID: CVE-2024-57935 State: PUBLISHED Published: 2025-01-21T12:01:31.236Z Last Updated: 2025-05-04T13:01:41.875Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix accessing invalid dip_ctx during destroying QP If it fails to modify QP to RTR, dip_ctx will not be attached. And during detroying QP, the invalid dip_ctx pointer will be accessed. References: - https://git.kernel.org/stable/c/a448c775f0aec6cfbee4bda561447c707153504a - https://git.kernel.org/stable/c/0572eccf239ce4bd89bd531767ec5ab20e249290
CVE ID: CVE-2024-57936 State: PUBLISHED Published: 2025-01-21T12:01:31.907Z Last Updated: 2025-05-04T10:07:02.896Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix max SGEs for the Work Request Gen P7 supports up to 13 SGEs for now. WQE software structure can hold only 6 now. Since the max send sge is reported as 13, the stack can give requests up to 13 SGEs. This is causing traffic failures and system crashes. Use the define for max SGE supported for variable size. This will work for both static and variable WQEs. References: - https://git.kernel.org/stable/c/3de1b50f055dc2ca7072a526cdda21f691c22dd9 - https://g
ic and variable WQEs. References: - https://git.kernel.org/stable/c/3de1b50f055dc2ca7072a526cdda21f691c22dd9 - https://git.kernel.org/stable/c/9a479088e0c8f6140b8c7752b563bc8c6c6dcc8c - https://git.kernel.org/stable/c/79d330fbdffd8cee06d8bdf38d82cb62d8363a27
CVE ID: CVE-2024-57937 State: REJECTED Published: 2025-01-21T12:09:14.482Z Last Updated: 2025-01-22T12:50:28.180Z Description: No description available.
CVE ID: CVE-2024-57938 State: PUBLISHED Published: 2025-01-21T12:09:15.412Z Last Updated: 2025-11-03T20:56:05.568Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sctp: Prevent autoclose integer overflow in sctp_association_init() While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e - https://git.kernel.org/stable/c/081bdb3a31674339313c
/git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e - https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53 - https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f - https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a - https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477 - https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94 - https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d
CVE ID: CVE-2024-57939 State: PUBLISHED Published: 2025-01-21T12:18:08.433Z Last Updated: 2025-11-03T20:56:06.960Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Fix sleeping in invalid context in die() die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlock_t which can sleep with PREEMPT_RT enabled. That causes the following warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex preempt_count: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285
lock: 0, pid: 285, name: mutex preempt_count: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dump_backtrace+0x1c/0x24 show_stack+0x2c/0x38 dump_stack_lvl+0x5a/0x72 dump_stack+0x14/0x1c __might_resched+0x130/0x13a rt_spin_lock+0x2a/0x5c die+0x24/0x112 do_trap_insn_illegal+0xa0/0xea _new_vmalloc_restore_context_a0+0xcc/0xd8 Oops - illegal instruction [#1] Switch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT enabled. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/
Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c38baa03ac8e18140faf36a3b955d30cad48e74 - https://git.kernel.org/stable/c/10c24df2e303f517fab0359392c11b6b1d553f2b - https://git.kernel.org/stable/c/c21df31fc2a4afc02a6e56511364e9e793ea92ec - https://git.kernel.org/stable/c/f48f060a4b36b5e96628f6c3fb1540f1e8dedb69 - https://git.kernel.org/stable/c/76ab0afcdbe8c9685b589016ee1c0e25fe596707 - https://git.kernel.org/stable/c/6a97f4118ac07cfdc316433f385dbdc12af5025e
CVE ID: CVE-2024-57940 State: PUBLISHED Published: 2025-01-21T12:18:09.150Z Last Updated: 2025-11-03T20:56:09.764Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: fix the infinite loop in exfat_readdir() If the file system is corrupted so that a cluster is linked to itself in the cluster chain, and there is an unused directory entry in the cluster, 'dentry' will not be incremented, causing condition 'dentry < max_dentries' unable to prevent an infinite loop. This infinite loop causes s_lock not to be released, and other tasks will hang, such as exfat_sync_fs(). This commit stops traversing the cluster chain when there is
eased, and other tasks will hang, such as exfat_sync_fs(). This commit stops traversing the cluster chain when there is unused directory entry in the cluster to avoid this infinite loop. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d8cfbb8723bd3d3222f360227a1cc15227189ca6 - https://git.kernel.org/stable/c/28c21f0ac5293a4bf19b3e0e32005d6dd31a6c17 - https://git.kernel.org/stable/c/31beabd0f47f8c3ed9965ba861c9e5b252d4920a - https://git.kernel.org/stable/c/dc1d7afceb982e8f666e70a582e6b5aa806de063 - https://git.kernel.org/stable/c/d9ea94f5cd117d56e573696d0045ab3044185a15 - https://git.kernel.org/stable/c/fee873761bd978d077d8c55334b4966ac4cb7b59
CVE ID: CVE-2024-57941 State: PUBLISHED Published: 2025-01-21T12:18:09.834Z Last Updated: 2025-05-04T10:07:08.541Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PG_private_2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfs_advance_write() will just bail at the first check see
ly used by ceph), and decides it wants to copy to the cache, netfs_advance_write() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content. This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PG_private_2 set. Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folio_queue list and netfs_pgpriv2_cancel() will clean up the folios. This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc
clean up the folios. This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang References: - https://git.kernel.org/stable/c/ba37bdfe59fb43e80dd79290340a21864ba4b61e - https://git.kernel.org/stable/c/d0327c824338cdccad058723a31d038ecd553409
CVE ID: CVE-2024-57942 State: PUBLISHED Published: 2025-01-21T12:18:10.532Z Last Updated: 2025-05-04T10:07:09.915Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix ceph copy to cache on write-begin At the end of netfs_unlock_read_folio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PG_private_2 set) and then unlocked, the folio_queue struct has the entry pointing to the folio cleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(), which is used to write folios marked with PG_private_2 to the cache as
problem for netfs_pgpriv2_write_to_the_cache(), which is used to write folios marked with PG_private_2 to the cache as it expects to be able to trawl the folio_queue list thereafter to find the relevant folios, leading to a hang. Fix this by not clearing the folio_queue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache. This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it. References: - https://git.kernel.org/stable/c/43b8d3249b0b71bad239d42dbe08ce6c938ba000 - https://git.kernel.org/stable/c/38cf8e945721ffe708fa675507465da7f4f2a9f7
CVE ID: CVE-2024-57943 State: PUBLISHED Published: 2025-01-21T12:18:11.195Z Last Updated: 2025-10-01T19:57:13.743Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: fix the new buffer was not zeroed before writing Before writing, if a buffer_head marked as new, its data must be zeroed, otherwise uninitialized data in the page cache will be written. So this commit uses folio_zero_new_buffers() to zero the new buffers before ->write_end(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/942c6f91ab8d82a41650e717940b4e577173762f - https://git.kernel.org/stable/c/98e2fb26d1a9eafe7
s://git.kernel.org/stable/c/942c6f91ab8d82a41650e717940b4e577173762f - https://git.kernel.org/stable/c/98e2fb26d1a9eafe79f46d15d54e68e014d81d8c
CVE ID: CVE-2024-57944 State: PUBLISHED Published: 2025-01-21T12:18:11.882Z Last Updated: 2025-10-01T19:57:13.622Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: adc: ti-ads1298: Add NULL check in ads1298_init devm_kasprintf() can return a NULL pointer on failure. A check on the return value of such a call in ads1298_init() is missing. Add it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/69b680bbac9bd611aaa308769d6c71e3e70eb3c3 - https://git.kernel.org/stable/c/bcb394bb28e55312cace75362b8e489eb0e02a30
CVE ID: CVE-2024-57945 State: PUBLISHED Published: 2025-01-21T12:18:12.548Z Last Updated: 2025-11-03T19:32:46.584Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Fix the out of bound issue of vmemmap address In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> P
age from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address in
new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/92f08673d3f1893191323572f60e3c62f2e57c2f - https://git.kernel.org/stable/c/a4a7ac3d266008018f05fae53060fcb331151a14 - https://git.kernel.org/stable/c/d2bd51954ac8377c2f1eb1813e694788998add66 - https://git.kernel.org/stable/c/f754f27e98f88428aaf6be6e00f5cbce97f62d4b
CVE ID: CVE-2024-57946 State: PUBLISHED Published: 2025-01-21T12:22:53.324Z Last Updated: 2025-11-03T20:56:12.738Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio-blk: don't keep queue frozen during system suspend Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current
se deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container:
r by keeping queue quiesced during suspend. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5 - https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2 - https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4 - https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4 - https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea - https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516 - https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37
CVE ID: CVE-2024-57947 State: PUBLISHED Published: 2025-01-23T13:54:20.267Z Last Updated: 2025-05-04T10:07:17.250Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo: fix initial map fill The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where fi
ne-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where first field size is not the largest. Followup patch adds a test case to nft_concat_range.sh selftest script. Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough. References: - https://git.kernel.org/stable/c/957a4d1c4c5849e4515c9fb4db21bf85318103dc - https://git.kernel.org/stable/c/9625c46ce6fd4f922595a4b32b1de5066d70464f - https://git.kernel.org/stable/c/69b6a67f7052905e928d75a0c5871de50e686986 - https://git.kernel.org/stable/c/8058c88ac0df21239daee54b5934d5c80ca9685f - https://git.kernel
928d75a0c5871de50e686986 - https://git.kernel.org/stable/c/8058c88ac0df21239daee54b5934d5c80ca9685f - https://git.kernel.org/stable/c/791a615b7ad2258c560f91852be54b0480837c93
CVE ID: CVE-2024-57948 State: PUBLISHED Published: 2025-01-31T11:25:29.762Z Last Updated: 2025-11-03T20:56:15.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mac802154: check local interfaces before deleting sdata list syzkaller reported a corrupted list in ieee802154_if_remove. [1] Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system. CPU0 CPU1 ==== ==== genl_family_rcv_msg_doit ieee802154_unregister_hw ieee802154_del_iface ieee802154_remove_interfaces rdev_del_virtual_intf_deprecated list_del(&sdata->list) ieee802154_if_remove list_del_rcu The net device has been unre
s rdev_del_virtual_intf_deprecated list_del(&sdata->list) ieee802154_if_remove list_del_rcu The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154_if_remove. To avoid this issue, add a check for local->interfaces before deleting sdata list. [1] kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37
4 RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(000
000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:124 [inline] __list_del_entry include/linux/list.h:215 [inline] list_del_rcu include/linux/rculist.h:157 [inline] ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687 rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline] i
_if_remove+0x86/0x1e0 net/mac802154/iface.c:687 rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0
netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:744 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607 ___sys_sendmsg net/socket.c:2661 [inline] __sys_sendmsg+0x292/0x380 net/socket.c:2690 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0d11dc30edfc4acef0acef130bb5ca596317190a - https://git.kernel.org/stable/c/98ea165a2ac240345c48b57c0a3d08bbcad02929 - https://git.kernel.org/stable/c/80aee0bc0dbe253b6692d33e64455
el.org/stable/c/98ea165a2ac240345c48b57c0a3d08bbcad02929 - https://git.kernel.org/stable/c/80aee0bc0dbe253b6692d33e64455dc742fc52f1 - https://git.kernel.org/stable/c/41e4ca8acba39f1cecff2dfdf14ace4ee52c4272 - https://git.kernel.org/stable/c/2e41e98c4e79edae338f2662dbdf74ac2245d183 - https://git.kernel.org/stable/c/b856d2c1384bc5a7456262afd21aa439ee5cdf6e - https://git.kernel.org/stable/c/eb09fbeb48709fe66c0d708aed81e910a577a30a
CVE ID: CVE-2024-57949 State: PUBLISHED Published: 2025-02-09T11:37:23.906Z Last Updated: 2025-11-03T20:56:17.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity() The following call-chain leads to enabling interrupts in a nested interrupt disabled section: irq_set_vcpu_affinity() irq_get_desc_lock() raw_spin_lock_irqsave() <--- Disable interrupts its_irq_set_vcpu_affinity() guard(raw_spinlock_irq) <--- Enables interrupts when leaving the guard() irq_put_desc_unlock() <--- Warns because interrupts are enabled This was broken in commit b97e8a2f7130, which r
guard() irq_put_desc_unlock() <--- Warns because interrupts are enabled This was broken in commit b97e8a2f7130, which replaced the original raw_spin_[un]lock() pair with guard(raw_spinlock_irq). Fix the issue by using guard(raw_spinlock). [ tglx: Massaged change log ] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d7b0e89610dd45ac6cf0d6f99bfa9ccc787db344 - https://git.kernel.org/stable/c/6c84ff2e788fce0099ee3e71a3ed258b1ca1a223 - https://git.kernel.org/stable/c/93955a7788121ab5a0f7f27e988b2ed1135a4866 - https://git.kernel.org/stable/c/35cb2c6ce7da545f3b5cb1e6473ad7c3a6f08310
CVE ID: CVE-2024-57950 State: PUBLISHED Published: 2025-02-10T15:58:42.107Z Last Updated: 2025-10-01T19:57:10.629Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominator defaults to 1 [WHAT & HOW] Variables, used as denominators and maybe not assigned to other values, should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported by Coverity. (cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c9d6afb4f9c338049662d27d169fba7dd60e337d - https://git.kernel.org/stable/c/36b23e3ba