Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-50131 State: PUBLISHED Published: 2024-11-05T17:10:56.981Z Last Updated: 2025-11-03T22:25:51.692Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5e3231b352725ff4a3a0095e6035af674f2d8725 - https://git.kernel.
Container: References: - https://git.kernel.org/stable/c/5e3231b352725ff4a3a0095e6035af674f2d8725 - https://git.kernel.org/stable/c/02874ca52df2ca2423ba6122039315ed61c25972 - https://git.kernel.org/stable/c/b86b0d6eea204116e4185acc35041ca4ff11a642 - https://git.kernel.org/stable/c/f4ed40d1c669bba1a54407d8182acdc405683f29 - https://git.kernel.org/stable/c/a14a075a14af8d622c576145455702591bdde09d - https://git.kernel.org/stable/c/5fd942598ddeed9a212d1ff41f9f5b47bcc990a7 - https://git.kernel.org/stable/c/0b6e2e22cb23105fcb171ab92f0f7516c69c8471
CVE ID: CVE-2024-50132 State: PUBLISHED Published: 2024-11-05T17:10:57.625Z Last Updated: 2025-10-01T20:27:15.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix MAX_TRACE_ARGS limit handling When creating a trace_probe we would set nr_args prior to truncating the arguments to MAX_TRACE_ARGS. However, we would only initialize arguments up to the limit. This caused invalid memory access when attempting to set up probes with more than 128 fetchargs. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 O
ss: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:__set_print_fmt+0x134/0x330 Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Return an error when there are too many arguments instead of silently truncating. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6bc24db74fe4788cc7c2f30a113fc6aafba225a3 - https://git.kernel.org/stable/c/08ccd1a57c4d3882e9a877eb2dcc66e50a3b0279
e/c/6bc24db74fe4788cc7c2f30a113fc6aafba225a3 - https://git.kernel.org/stable/c/08ccd1a57c4d3882e9a877eb2dcc66e50a3b0279 - https://git.kernel.org/stable/c/73f35080477e893aa6f4c8d388352b871b288fbc
CVE ID: CVE-2024-50133 State: PUBLISHED Published: 2024-11-05T17:10:58.264Z Last Updated: 2025-11-03T22:25:53.158Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [
ut+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a67d4a02bf43e15544179895ede7d5f97b84b550 - https://git.kernel.org/stable/c/a94c197d4d749954dfaa37e907fcc8c04e4aad7e - https://git.kernel.org/stable/c/041c
84b550 - https://git.kernel.org/stable/c/a94c197d4d749954dfaa37e907fcc8c04e4aad7e - https://git.kernel.org/stable/c/041cc3860b06770357876d1114d615333b0fbf31 - https://git.kernel.org/stable/c/134475a9ab8487527238d270639a8cb74c10aab2
CVE ID: CVE-2024-50134 State: PUBLISHED Published: 2024-11-05T17:10:58.939Z Last Updated: 2025-11-03T22:25:54.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_poi
ase.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617 - https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a
org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617 - https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a1ecf2331 - https://git.kernel.org/stable/c/34a422274b693507025a7db21519865d1862afcb - https://git.kernel.org/stable/c/7458a6cdaebb3dc59af8578ee354fae78a154c4a - https://git.kernel.org/stable/c/9eb32bd23bbcec44bcbef27b7f282b7a7f3d0391 - https://git.kernel.org/stable/c/fae9dc12c61ce23cf29d09824a741b7b1ff8f01f - https://git.kernel.org/stable/c/d92b90f9a54d9300a6e883258e79f36dab53bfae
CVE ID: CVE-2024-50135 State: PUBLISHED Published: 2024-11-05T17:10:59.591Z Last Updated: 2025-10-01T20:27:14.820Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvme_dev_disable() nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: <TAS
+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: <TASK> ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4ed32cc0939b64e3d7b48c8c0d63ea038775f304 - https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc2
g/stable/c/4ed32cc0939b64e3d7b48c8c0d63ea038775f304 - https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc247a0be - https://git.kernel.org/stable/c/26bc0a81f64ce00fc4342c38eeb2eddaad084dd2
CVE ID: CVE-2024-50136 State: PUBLISHED Published: 2024-11-05T17:11:00.231Z Last Updated: 2025-11-03T22:25:56.068Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Unregister notifier on eswitch init failure It otherwise remains registered and a subsequent attempt at eswitch enabling might trigger warnings of the sort: [ 682.589148] ------------[ cut here ]------------ [ 682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663]
otifier.c:31 notifier_chain_register+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663] ? __warn+0x7c/0x110 [ 682.611050] ? notifier_chain_register+0x3e/0x90 [ 682.611556] ? report_bug+0x148/0x170 [ 682.611977] ? handle_bug+0x36/0x70 [ 682.612384] ? exc_invalid_op+0x13/0x60 [ 682.612817] ? asm_exc_invalid_op+0x16/0x20 [ 682.613284] ? notifier_chain_register+0x3e/0x90 [ 682.613789] atomic_notifier_chain_register+0x25/0x40 [ 682.614322] mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core] [ 682.614965] mlx5_eswitch_enable+0xc9/0x100 [mlx5_core] [ 682.615551] mlx5_device_enable_sriov+0x25/0x340 [mlx5_core] [ 682.616170] mlx5_core_sriov_configure+0x50/0x170 [mlx5_c
[ 682.615551] mlx5_device_enable_sriov+0x25/0x340 [mlx5_core] [ 682.616170] mlx5_core_sriov_configure+0x50/0x170 [mlx5_core] [ 682.616789] sriov_numvfs_store+0xb0/0x1b0 [ 682.617248] kernfs_fop_write_iter+0x117/0x1a0 [ 682.617734] vfs_write+0x231/0x3f0 [ 682.618138] ksys_write+0x63/0xe0 [ 682.618536] do_syscall_64+0x4c/0x100 [ 682.618958] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e58fb7ddbab6635191c26dea1af26b91cce00866 - https://git.kernel.org/stable/c/9f2ccb6f3888bec45c00121ee43e4e72423b12c1 - https://git.kernel.org/stable/c/599147722c5778c96292e2fbff4103abbdb45b1f - htt
f2ccb6f3888bec45c00121ee43e4e72423b12c1 - https://git.kernel.org/stable/c/599147722c5778c96292e2fbff4103abbdb45b1f - https://git.kernel.org/stable/c/1da9cfd6c41c2e6bbe624d0568644e1521c33e12
CVE ID: CVE-2024-50137 State: PUBLISHED Published: 2024-11-05T17:11:00.861Z Last Updated: 2025-05-04T09:47:00.453Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC data->asserted will be NULL on JH7110 SoC since commit 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add the judgment condition to avoid errors when calling reset_control_status on JH7110 SoC. References: - https://git.kernel.org/stable/c/3918b2016d28c9b2bddd5ab194ab366a4e2310f5 - https://git.kernel.org/stable/c/c923f1fb8ae8627322d167b73bb4f978404a05de - https://git.ke
c9b2bddd5ab194ab366a4e2310f5 - https://git.kernel.org/stable/c/c923f1fb8ae8627322d167b73bb4f978404a05de - https://git.kernel.org/stable/c/2cf59663660799ce16f4dfbed97cdceac7a7fa11
CVE ID: CVE-2024-50138 State: PUBLISHED Published: 2024-11-05T17:11:01.518Z Last Updated: 2025-11-03T22:25:57.730Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest d
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f
2a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5eb34999d118e69a20dc0c6556f315fcb0a1f8d3 - https://git.kernel.org/stable/c/f9543375d9b150b2bcf16bb182e6b62309db0888 - https://git.kernel.org/stable/c/ca30e682e5d6de44d12c4610767811c9a21d59ba - https://git.kernel.org/stable/c/8b62645b09f870d70c7910e7550289d
.org/stable/c/ca30e682e5d6de44d12c4610767811c9a21d59ba - https://git.kernel.org/stable/c/8b62645b09f870d70c7910e7550289d444239a46
CVE ID: CVE-2024-50139 State: PUBLISHED Published: 2024-11-07T09:31:15.925Z Last Updated: 2025-10-01T20:27:14.564Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix shift-out-of-bounds bug Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_l
l MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Additional Analyst Notes: - CISA ADP Vulnrichment: References: -
t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/04ed2ba07ce73f323052475fbd33d647aca3ff2e - https://git.kernel.org/stable/c/4b9e11794d910aa55300debbac5f0adcc42c491a - https://git.kernel.org/stable/c/c6c167afa090ea0451f91814e1318755a8fb8bb9
CVE ID: CVE-2024-50140 State: PUBLISHED Published: 2024-11-07T09:31:17.379Z Last Updated: 2025-10-01T20:27:14.428Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/core: Disable page allocation in task_tick_mm_cid() With KASAN and PREEMPT_RT enabled, calling task_work_add() in task_tick_mm_cid() may cause the following splat. [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1 This problem is caused by
obe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1 This problem is caused by the following call trace. sched_tick() [ acquire rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock() The rq lock is a raw_spinlock_t. We can't sleep while holding it. IOW, we can't call alloc_pages() in stack_depot_save_flags(). The task_tick_mm_cid() function with its task_work_add() call was introduced by commit 223ba
n stack_depot_save_flags(). The task_tick_mm_cid() function with its task_work_add() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") in v6.4 kernel. Fortunately, there is a kasan_record_aux_stack_noalloc() variant that calls stack_depot_save_flags() while not allowing it to allocate new pages. To allow task_tick_mm_cid() to use task_work without page allocation, a new TWAF_NO_ALLOC flag is added to enable calling kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack() if set. The task_tick_mm_cid() function is modified to add this new flag. The possible downside is the missing stack trace in a KASAN report due to new page all
is modified to add this new flag. The possible downside is the missing stack trace in a KASAN report due to new page allocation required when task_work_add_noallloc() is called which should be rare. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/509c29d0d26f68a6f6d0a05cb1a89725237e2b87 - https://git.kernel.org/stable/c/ce0241ef83eed55f675376e8a3605d23de53d875 - https://git.kernel.org/stable/c/73ab05aa46b02d96509cb029a8d04fca7bbde8c7
CVE ID: CVE-2024-50141 State: PUBLISHED Published: 2024-11-07T09:31:18.461Z Last Updated: 2025-11-03T22:25:59.519Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM
f the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtim
hout proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8df52929530839e878e6912e33348b54101e3250 - https://git.kernel.org/stable/c/8c
erences: - https://git.kernel.org/stable/c/8df52929530839e878e6912e33348b54101e3250 - https://git.kernel.org/stable/c/8ce081ad842510f0e70fa6065a401660eac876d4 - https://git.kernel.org/stable/c/795b080d9aa127215a5baf088a22fa09341a0126 - https://git.kernel.org/stable/c/20e9fafb8bb6f545667d7916b0e81e68c0748810 - https://git.kernel.org/stable/c/088984c8d54c0053fc4ae606981291d741c5924b
CVE ID: CVE-2024-50142 State: PUBLISHED Published: 2024-11-07T09:31:19.415Z Last Updated: 2025-11-03T22:26:01.031Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_I
ewsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f31398570acf0f0804c644006f7bfa9067106b0a - https://git.kernel.org/stable/c/401ad99a5ae7180dd9449eac104cb755f442e7f3 - https://git.kernel.org/stable/c/8df5cd51fd70c33aa1776e5cbcd82b0a86649d73 - https://git.kernel.org/stable/c/2d08a6c31c65f23db71a5385ee9cf9d8f9a67a71 - https://git.kernel.org/stable/c/bce1afaa212ec380
ps://git.kernel.org/stable/c/2d08a6c31c65f23db71a5385ee9cf9d8f9a67a71 - https://git.kernel.org/stable/c/bce1afaa212ec380bf971614f70909a27882b862 - https://git.kernel.org/stable/c/7d9868180bd1e4cf37e7c5067362658971162366 - https://git.kernel.org/stable/c/e68dd80ba498265d2266b12dc3459164f4ff0c4a - https://git.kernel.org/stable/c/3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563
CVE ID: CVE-2024-50143 State: PUBLISHED Published: 2024-11-07T09:31:20.340Z Last Updated: 2025-11-03T22:26:02.747Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git
t?x=10242227980000 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5eb76fb98b3335aa5cca6a7db2e659561c79c32b - https://git.kernel.org/stable/c/417bd613bdbe791549f7687bb1b9b8012ff111c2 - https://git.kernel.org/stable/c/0ce61b1f6b32df822b59c680cbe8e5ba5d335742 - https://git.kernel.org/stable/c/4fc0d8660e391dcd8dde23c44d702be1f6846c61 - https://git.kernel.org/stable/c/72e445df65a0aa9066c6fe2b8736ba2fcca6dac7 - https://git.kernel.org/stable/c/1ac49babc952f48d82676979b20885e480e69be8 - https://git.kernel.org/stable/c/e52e0b92ed31dc62afbda15c243dcee0bb5bb58d - https://git.kernel.org/stable/c/264db9d666ad9a35075cc9ed9ec09d0215
g/stable/c/e52e0b92ed31dc62afbda15c243dcee0bb5bb58d - https://git.kernel.org/stable/c/264db9d666ad9a35075cc9ed9ec09d021580fbb1
CVE ID: CVE-2024-50144 State: PUBLISHED Published: 2024-11-07T09:31:21.224Z Last Updated: 2025-10-01T20:27:13.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix unbalanced rpm put() with fence_fini() Currently we can call fence_fini() twice if something goes wrong when sending the GuC CT for the tlb request, since we signal the fence and return an error, leading to the caller also calling fini() on the error path in the case of stack version of the flow, which leads to an extra rpm put() which might later cause device to enter suspend when it shouldn't. It looks like we can just drop the fini() call since the fence