CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26742 – scsi: smartpqi: Fix disable_managed_interrupts
https://notcve.org/view.php?id=CVE-2024-26742
In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? • https://git.kernel.org/stable/c/cf15c3e734e8d25de7b4d9170f5a69ace633a583 https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26740 – net/sched: act_mirred: use the backlog for mirred ingress
https://notcve.org/view.php?id=CVE-2024-26740
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. • https://git.kernel.org/stable/c/53592b3640019f2834701093e38272fdfd367ad8 https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4 https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17 https://access.redhat.com/security/cve/CVE-2024-26740 https://bugzilla.redhat.com/show_bug.cgi?id=2273268 • CWE-833: Deadlock •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26739 – net/sched: act_mirred: don't override retval if we already lost the skb
https://notcve.org/view.php?id=CVE-2024-26739
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_mirred: no anula retval si ya perdimos el skb. Si estamos redirigiendo el skb y aún no hemos llamado a tcf_mirred_forward(), necesitamos para decirle al núcleo que suelte el skb configurando el código de retección en SHOT. Sin embargo, si hemos llamado a tcf_mirred_forward(), el skb está fuera de nuestras manos y devolver SHOT conducirá a UaF. • https://git.kernel.org/stable/c/e5cf1baf92cb785b90390db1c624948e70c8b8bd https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7 https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210 https://access.redhat.com/security/cve/CVE-2024-26739 https://bugzilla.redhat.com/show_bug.cgi?id=2273270 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26737 – bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel
https://notcve.org/view.php?id=CVE-2024-26737
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. • https://git.kernel.org/stable/c/b00628b1c7d595ae5b544e059c27b1f5828314b4 https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5 https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6 https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33 https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f https://access.redhat.com/security/cve/CVE-2024-26737 https://bugzilla.redhat.com/show_bug.cgi?id=2273274 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26736 – afs: Increase buffer size in afs_update_volume_status()
https://notcve.org/view.php?id=CVE-2024-26736
In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: aumenta el tamaño del búfer en afs_update_volume_status() La longitud máxima del volumen->valor vid es de 20 caracteres. Por lo tanto, aumente el tamaño de idbuf[] hasta 24 para evitar el desbordamiento. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [DH: En realidad, es 20 + NUL, así que auméntalo a 24 y usa snprintf()] • https://git.kernel.org/stable/c/d2ddc776a4581d900fc3bdc7803b403daae64d88 https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5 https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637 https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1 https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fb •