CVSS: 2.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-33621 – ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
https://notcve.org/view.php?id=CVE-2024-33621
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 https://git.kernel.org/stable/c/0049a623dfbbb49888de7f0c2f33a582b5ead989 https://git.kernel.org/stable/c/54768bacfde60e8e4757968d79f8726711dd2cf5 https://git.kernel.org/stable/c/1abbf079da59ef559d0ab4219d2a0302f7970761 https://git.kernel.org/stable/c/183c4b416454b9983dc1b8aa0022b748911adc48 https://git.kernel.org/stable/c/cb53706a3403ba67f4040b2a82d9cf79e11b1a48 https://git.kernel.org/stable/c/54213c09801e0bd2549ac42961093be36f65a7d0 https://git.kernel.org/stable/c/13c4543db34e0da5a7d2f550b6262d860 • CWE-20: Improper Input Validation •
CVSS: 5.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-31076 – genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
https://notcve.org/view.php?id=CVE-2024-31076
In the Linux kernel, the following vulnerability has been resolved: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. • https://git.kernel.org/stable/c/f0383c24b4855f6a4b5a358c7b2d2c16e0437e9b https://git.kernel.org/stable/c/a40209d355afe4ed6d533507838c9e5cd70a76d8 https://git.kernel.org/stable/c/f5f4675960609d8c5ee95f027fbf6ce380f98372 https://git.kernel.org/stable/c/6752dfcfff3ac3e16625ebd3f0ad9630900e7e76 https://git.kernel.org/stable/c/9eeda3e0071a329af1eba15f4e57dc39576bb420 https://git.kernel.org/stable/c/e9c96d01d520498b169ce734a8ad1142bef86a30 https://git.kernel.org/stable/c/59f86a2908380d09cdc726461c0fbb8d8579c99f https://git.kernel.org/stable/c/ebfb16fc057a016abb46a9720a54abf0d • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-4439 – isdn: cpai: check ctr->cnr to avoid array index out of bound
https://notcve.org/view.php?id=CVE-2021-4439
In the Linux kernel, the following vulnerability has been resolved: isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d", session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] • https://git.kernel.org/stable/c/e8b8de17e164c9f1b7777f1c6f99d05539000036 https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a https://git.kernel.org/stable/c/9b6b2db77bc3121fe435f1d4b56e34de443bec75 https://git.kernel.org/stable/c/7d91adc0ccb060ce564103315189466eb822cc6a https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54 https://git.kernel.org/stable/c/7f221ccbee4ec662e2292d490a43ce6c314c4594 https://git.kernel.org/stable/c/cc20226e218a2375d50dd9ac14fb4121b43375ff https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787 •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48771 – drm/vmwgfx: Fix stale file descriptors on failed usercopy
https://notcve.org/view.php?id=CVE-2022-48771
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. • https://git.kernel.org/stable/c/c906965dee22d5e95d0651759ba107b420212a9f https://git.kernel.org/stable/c/e8d092a62449dcfc73517ca43963d2b8f44d0516 https://git.kernel.org/stable/c/0008a0c78fc33a84e2212a7c04e6b21a36ca6f4d https://git.kernel.org/stable/c/84b1259fe36ae0915f3d6ddcea6377779de48b82 https://git.kernel.org/stable/c/ae2b20f27732fe92055d9e7b350abc5cdf3e2414 https://git.kernel.org/stable/c/6066977961fc6f437bc064f628cf9b0e4571c56c https://git.kernel.org/stable/c/1d833b27fb708d6fdf5de9f6b3a8be4bd4321565 https://git.kernel.org/stable/c/a0f90c8815706981c483a652a6aefca51 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48769 – efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
https://notcve.org/view.php?id=CVE-2022-48769
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/ • https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807 https://git.kernel.org/stable/c/3df52448978802ae15dcebf66beba1029df957b4 https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684 https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 •