CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36281 – net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules
https://notcve.org/view.php?id=CVE-2024-36281
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules rx_create no longer allocates a modify_hdr instance that needs to be cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer dereference. A leak in the rules also previously occurred since there are now two rules populated related to status. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 109907067 P4D 109907067 PUD 116890067 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70 <snip> Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x24/0x70 ? • https://git.kernel.org/stable/c/20af7afcd8b85a4cb413072d631bf9a6469eee3a https://git.kernel.org/stable/c/94af50c0a9bb961fe93cf0fdd14eb0883da86721 https://git.kernel.org/stable/c/b0a15cde37a8388e57573686f650a17208ae1212 https://git.kernel.org/stable/c/cc9ac559f2e21894c21ac5b0c85fb24a5cab266c https://git.kernel.org/stable/c/16d66a4fa81da07bc4ed19f4e53b87263c2f8d38 •
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: 4.4EPSS: 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 •
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 •