CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36270 – netfilter: tproxy: bail out if IP has been disabled on the device
https://notcve.org/view.php?id=CVE-2024-36270
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this. • https://git.kernel.org/stable/c/cc6eb433856983e91071469c4ce57accb6947ccb https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03 https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80 https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0 https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36244 – net/sched: taprio: extend minimum interval restriction to entire cycle too
https://notcve.org/view.php?id=CVE-2024-36244
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot. • https://git.kernel.org/stable/c/b5b73b26b3ca34574124ed7ae9c5ba8391a7f176 https://git.kernel.org/stable/c/83bd58952b2b8543d8c48d1453975ab47a0a7504 https://git.kernel.org/stable/c/817ff50796c5e364c879596509f83fcba194bb6f https://git.kernel.org/stable/c/b939d1e04a90248b4cdf417b0969c270ceb992b2 https://git.kernel.org/stable/c/91f249b01fe490fce11fbb4307952ca8cce78724 https://git.kernel.org/stable/c/fb66df20a7201e60f2b13d7f95d031b31a8831d3 https://access.redhat.com/security/cve/CVE-2024-36244 https://bugzilla.redhat.com/show_bug.cgi?id=2293654 • CWE-20: Improper Input Validation •
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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-33619 – efi: libstub: only free priv.runtime_map when allocated
https://notcve.org/view.php?id=CVE-2024-33619
In the Linux kernel, the following vulnerability has been resolved: efi: libstub: only free priv.runtime_map when allocated priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. • https://git.kernel.org/stable/c/f80d26043af91ceb5036c478101c015edb9e7630 https://git.kernel.org/stable/c/b8938d6f570f010a1dcdbfed3e5b5d3258c2a908 https://git.kernel.org/stable/c/9dce01f386c9ce6990c0a83fa14b1c95330b037e https://git.kernel.org/stable/c/6ca67a5fe1c606d1fbe24c30a9fc0bdc43a18554 https://git.kernel.org/stable/c/4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 •
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') •