CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26741 – dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
https://notcve.org/view.php?id=CVE-2024-26741
In the Linux kernel, the following vulnerability has been resolved: dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). syzkaller reported a warning [0] in inet_csk_destroy_sock() with no repro. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); However, the syzkaller's log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1] When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable. If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num. Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist. Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). • https://git.kernel.org/stable/c/28044fc1d4953b07acec0da4d2fc4784c57ea6fb https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131 https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39 https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f •
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 •