Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ol+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncated--- References: - https://git.ker
[inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncated--- References: - https://git.kernel.org/stable/c/0b19171439016a8e4c97eafe543670ac86e2b8fe - https://git.kernel.org/stable/c/4026033907cc6186d86b48daa4a252c860db2536 - https://git.kernel.org/stable/c/9e481d87349d2282f400ee1d010a169c99f766b8 - https://git.kernel.org/stable/c/78be2ee0112409ae4e9ee9e326151e0559b3d239 - https://git.kernel.org/stable/c/35309be06b6feded2ab2cafbc2bca8534c2fa41e - https://git.kernel.org/stable/c/b49026d9c86f35a4c5bfb8d7345c9c4379828c6b - https://git.kernel.org/stable/c/1b639be27cbf428a5ca01dcf8b5d654194c956f8 - https://git.kernel.org/stable/c/72e560cb8c6f80fc2b4afc5d3634a32465e13a
able/c/1b639be27cbf428a5ca01dcf8b5d654194c956f8 - https://git.kernel.org/stable/c/72e560cb8c6f80fc2b4afc5d3634a32465e13a51
CVE ID: CVE-2022-49776 State: PUBLISHED Published: 2025-05-01T14:09:12.572Z Last Updated: 2025-05-04T08:45:07.682Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: macvlan: enforce a consistent minimal mtu macvlan should enforce a minimal mtu of 68, even at link creation. This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up) $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff
ST> mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu less than device minimum. References: - https://git.kernel.org/stable/c/d2fee7d121d189c6dc905b727d60e7043a6655bb - https://git.kernel.org/stable/c/650137a7c0b2892df2e5b0bc112d7b09a78c93c8 - https://git.kernel.org/stable/c/a62aa84fe19eb24d083d600a074c009a0a66d4f3 - https://git.kernel.org/stable/c/e929ec98c0c3b10d9c07f3776df0c1a02d7a763e - https://git.kernel.org/stable/c/e41cbf98df22d08402e65174d147cbb187fe1a33 - https://git.kernel.org/stabl
f0c1a02d7a763e - https://git.kernel.org/stable/c/e41cbf98df22d08402e65174d147cbb187fe1a33 - https://git.kernel.org/stable/c/2b055c719d8f94c15ec9b7659978133030c6a353 - https://git.kernel.org/stable/c/b64085b00044bdf3cd1c9825e9ef5b2e0feae91a
CVE ID: CVE-2022-49777 State: PUBLISHED Published: 2025-05-01T14:09:13.199Z Last Updated: 2025-05-04T08:45:09.190Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: i8042 - fix leaking of platform device on module removal Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload. References: - https://git.kernel.org/stable/c/81df118e79b2136b5c016394f67a051dc508b7b6 - https://git.kernel.org/stable/c/4f348b60c79671eee33c1389efe89109c93047da - https://git.kernel.org/stable/c/3f25add5ecf88de0f8ff2b27b6c0731a1f1b
stable/c/4f348b60c79671eee33c1389efe89109c93047da - https://git.kernel.org/stable/c/3f25add5ecf88de0f8ff2b27b6c0731a1f1b38ed - https://git.kernel.org/stable/c/d5f7f6e63fed9c2ed09725d90059a28907e197e3 - https://git.kernel.org/stable/c/a32cd7feb0127bf629a82686b6e2c128139a86e5 - https://git.kernel.org/stable/c/81cd7e8489278d28794e7b272950c3e00c344e44
CVE ID: CVE-2022-49778 State: PUBLISHED Published: 2025-05-01T14:09:13.828Z Last Updated: 2025-05-04T08:45:10.804Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud The page table check trigger BUG_ON() unexpectedly when collapse hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:82! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DI
ugepaged Not tainted 6.1.0-rc3+ #750 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_clear.isra.0+0x258/0x3f0 lr : page_table_check_clear.isra.0+0x240/0x3f0 [...] Call trace: page_table_check_clear.isra.0+0x258/0x3f0 __page_table_check_pmd_clear+0xbc/0x108 pmdp_collapse_flush+0xb0/0x160 collapse_huge_page+0xa08/0x1080 hpage_collapse_scan_pmd+0xf30/0x1590 khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8 khugepaged+0x338/0x518 kthread+0x278/0x2f8 ret_from_fork+0x10/0x20 [...] Since pmd_user_accessible_page() doesn't check if a pmd is leaf, it decrease file_map_count for a non-leaf pmd comes from collapse_huge_page(). and
age() doesn't check if a pmd is leaf, it decrease file_map_count for a non-leaf pmd comes from collapse_huge_page(). and so trigger BUG_ON() unexpectedly. Fix this problem by using pmd_leaf() insteal of pmd_present() in pmd_user_accessible_page(). Moreover, use pud_leaf() for pud_user_accessible_page() too. References: - https://git.kernel.org/stable/c/2d458046df634088611d44fd77f45465e833ef78 - https://git.kernel.org/stable/c/5b47348fc0b18a78c96f8474cc90b7525ad1bbfe
CVE ID: CVE-2022-49779 State: PUBLISHED Published: 2025-05-01T14:09:14.445Z Last Updated: 2025-05-04T08:45:12.098Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a
), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free: Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0 __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_6
+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. References: - https://git.kernel.org/stable/c/7b0007b28dd970176f2e297c06ae63eea2447127 - https://git.kernel.org/stable/c/7d606ae1abcc3eab5408e42444d789dc7def51b8 - https://git.kernel.org/stable/c/c49cc2c059b503e962c2f13a806c105f9b757df4 - https://git.kernel.org/stable/c/55788ebbe8b365b4375bd56b4ba7db79d393a370 - https://git.kernel.org/stable/c/5dd7caf0bdc5d0b
tps://git.kernel.org/stable/c/55788ebbe8b365b4375bd56b4ba7db79d393a370 - https://git.kernel.org/stable/c/5dd7caf0bdc5d0bae7cf9776b4d739fb09bd5ebb
CVE ID: CVE-2022-49780 State: PUBLISHED Published: 2025-05-01T14:09:15.135Z Last Updated: 2025-05-04T08:45:13.302Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in
ed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case. References: - https://git.kernel.org/stable/c/41a6b8b527a5957fab41c3c05e25ad125268e2e9 - https://git.kernel.org/stable/c/28f7ff5e7559d226e63c7c5de74eb075a83d8c53 - https://git.kernel.org/stable/c/75205f1b47a88c3fac4f30bd7567e89b2887c7fd - https://git.kernel.org/stable/c/a636772988bafab89278e7bb3420d8e8eacfe912 - https://git.kernel.org/stable/c/dce0589a3faec9e2e543e97bca7e62592ec85585 - https://git.kernel.org/stable/c/bc68e428d4963af0201e92159629ab96948f0893
CVE ID: CVE-2022-49781 State: PUBLISHED Published: 2025-05-01T14:09:15.775Z Last Updated: 2025-05-04T08:45:14.518Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sam
nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer
nt page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not e
We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. References: - https://git.kernel.org/stable/c/fd5e454b856ed86b090336e269695d9908609b71 - https://git.kernel.org/stable/c/baa014b9543c8e5e94f5d15b66abfe60750b8284
CVE ID: CVE-2022-49782 State: PUBLISHED Published: 2025-05-01T14:09:16.430Z Last Updated: 2025-05-04T08:45:15.611Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf: Improve missing SIGTRAP checking To catch missing SIGTRAP we employ a WARN in __perf_event_overflow(), which fires if pending_sigtrap was already set: returning to user space without consuming pending_sigtrap, and then having the event fire again would re-enter the kernel and trigger the WARN. This, however, seemed to miss the case where some events not associated with progress in the user space task can fire and the interrupt handler runs before the IRQ work mea
ents not associated with progress in the user space task can fire and the interrupt handler runs before the IRQ work meant to consume pending_sigtrap (and generate the SIGTRAP). syzbot gifted us this stack trace: | WARNING: CPU: 0 PID: 3607 at kernel/events/core.c:9313 __perf_event_overflow | Modules linked in: | CPU: 0 PID: 3607 Comm: syz-executor100 Not tainted 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313 | <...> | Call Trace: | <TASK> | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtime
| Call Trace: | <TASK> | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtimer.c:1685 [inline] | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749 | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline] | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113 | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107 | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649 | <...> | </TASK> In this case, syzbot produced a program with event type PERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer
this case, syzbot produced a program with event type PERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer manages to fire again before the IRQ work got a chance to run, all while never having returned to user space. Improve the WARN to check for real progress in user space: approximate this by storing a 32-bit hash of the current IP into pending_sigtrap, and if an event fires while pending_sigtrap still matches the previous IP, we assume no progress (false negatives are possible given we could return to user space and trigger again on the same IP). References: - https://git.kernel.org/stable/c/35c60b4e8ca76712dd03bafe2598e31578248916 - https://git.kernel.org/stable/c/b09221f1b
: - https://git.kernel.org/stable/c/35c60b4e8ca76712dd03bafe2598e31578248916 - https://git.kernel.org/stable/c/b09221f1b4944d2866d06ac35e59d7a6f8916c9f - https://git.kernel.org/stable/c/bb88f9695460bec25aa30ba9072595025cf6c8af
CVE ID: CVE-2022-49783 State: PUBLISHED Published: 2025-05-01T14:09:17.054Z Last Updated: 2025-05-04T08:45:16.690Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Drop fpregs lock before inheriting FPU permissions Mike Galbraith reported the following against an old fork of preempt-rt but the same issue also applies to the current preempt-rt tree. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: fpu_clone CPU: 6 PID: 1 Comm: syst
preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) Call Trace: <TASK> dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe </TASK> Mike says: The splat comes from fpu_inherit_perms() being called under fpregs_lock(), and us reaching the spin_lock_irq() therein du
he splat comes from fpu_inherit_perms() being called under fpregs_lock(), and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic() returning true despite static key __fpu_state_size_dynamic having never been enabled. Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This problem exists since commit 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features"). Even though the original bug report should not have enabled the paths at all, the bug still exists. fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary f
bug still exists. fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary for fpu_inherit_perms(). The only write of any FP state in fpu_inherit_perms() is for the new child which is not running yet and cannot context switch or be borrowed by a kernel thread yet. Hence, fpregs_lock is not protecting anything in the new child until clone() completes and can be dropped earlier. The siglock still needs to be acquired by fpu_inherit_perms() as the read of the parent's permissions has to be serialised. [ bp: Cleanup splat. ] References: - https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0 - https://git.kernel.org/stable/c/36b03879
s: - https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0 - https://git.kernel.org/stable/c/36b038791e1e2baea892e9276588815fd14894b4
CVE ID: CVE-2022-49784 State: PUBLISHED Published: 2025-05-01T14:09:17.695Z Last Updated: 2025-05-04T08:45:17.907Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/uncore: Fix memory leak for events array When a CPU comes online, the per-CPU NB and LLC uncore contexts are freed but not the events array within the context structure. This causes a memory leak as identified by the kmemleak detector. [...] unreferenced object 0xffff8c5944b8e320 (size 32): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00
151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 un
el_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8c5944b8dd40 (size 64): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_
__cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 [...] Fix the problem by freeing the events array before freeing the uncore context. References: - https://git.kernel.org/stable/c/f75be9885d49e3717de962345c4572ddab52b178 - https://git.kernel.org/stable/c/bdfe34597139cfcecd47a2eb97fea44d77157491
CVE ID: CVE-2022-49785 State: PUBLISHED Published: 2025-05-01T14:09:18.311Z Last Updated: 2025-05-04T08:45:19.440Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Add overflow check in sgx_validate_offset_length() sgx_validate_offset_length() function verifies "offset" and "length" arguments provided by userspace, but was missing an overflow check on their addition. Add it. References: - https://git.kernel.org/stable/c/5277e3d633a5d4157987f4aff068caa55e36db19 - https://git.kernel.org/stable/c/3b1c10fb754b0b67165e3f055a4208e5ba26dc89 - https://git.kernel.org/stable/c/f0861f49bd946ff94fce4f82509c45e167f63690
CVE ID: CVE-2022-49786 State: PUBLISHED Published: 2025-05-01T14:09:18.954Z Last Updated: 2025-05-04T08:45:20.699Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: properly pin the parent in blkcg_css_online blkcg_css_online is supposed to pin the blkcg of the parent, but 397c9f46ee4d refactored things and along the way, changed it to pin the css instead. This results in extra pins, and we end up leaking blkcgs and cgroups. References: - https://git.kernel.org/stable/c/d118247e404d6338f7b90636a3c6b95a387ed163 - https://git.kernel.org/stable/c/d7dbd43f4a828fa1d9a8614d5b0ac40aee6375fe
CVE ID: CVE-2022-49787 State: PUBLISHED Published: 2025-05-01T14:09:19.731Z Last Updated: 2025-05-04T08:45:21.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case. References: - https://git.kernel.org/stable/c/7570e5b5419ffd34b6dc45a88c51e113a9a187e3 - https://git.kernel.or
ter case. References: - https://git.kernel.org/stable/c/7570e5b5419ffd34b6dc45a88c51e113a9a187e3 - https://git.kernel.org/stable/c/5dbd6378dbf96787d6dbcca44156c511ae085ea3 - https://git.kernel.org/stable/c/27f712cd47d65e14cd52cc32a23d42aeef583d5d - https://git.kernel.org/stable/c/4423866d31a06a810db22062ed13389416a66b22 - https://git.kernel.org/stable/c/a99a547658e5d451f01ed307426286716b6f01bf - https://git.kernel.org/stable/c/35bca18092685b488003509fef7055aa2d4f2ebc - https://git.kernel.org/stable/c/222cfa0118aa68687ace74aab8fdf77ce8fbd7e6
CVE ID: CVE-2022-49788 State: PUBLISHED Published: 2025-05-01T14:09:20.506Z Last Updated: 2025-05-04T08:45:22.950Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagr