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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26738 – powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller
https://notcve.org/view.php?id=CVE-2024-26738
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller When a PCI device is dynamically added, the kernel oopses with a NULL pointer dereference: BUG: Kernel NULL pointer dereference on read at 0x00000030 Faulting instruction address: 0xc0000000006bbe5c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Call Trace: iommu_init_device+0x26c/0x318 (unreliable) iommu_device_link+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains") broke DLPAR add of PCI devices. The above added iommu_device structure to pci_controller. During system boot, PCI devices are discovered and this newly added iommu_device structure is initialized by a call to iommu_device_register(). During DLPAR add of a PCI device, a new pci_controller structure is allocated but there are no calls made to iommu_device_register() interface. Fix is to register the iommu device during DLPAR add as well. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: la adición de DLPAR no inicializa completamente pci_controller Cuando se agrega dinámicamente un dispositivo PCI, el kernel falla con una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel activado leído en 0x00000030 Dirección de instrucción errónea: 0xc0000000006bbe5c Vaya: acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 Módulos NUMA pSeries vinculados en: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_r pcgss nfsv4 dns_resolver nfs lockd gracia fscache netfs xsk_diag vinculación nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5 _ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod CPU fusible : 17 PID: 2685 Comm: drmgr No contaminado 6.7.0-203405+ #66 Nombre de hardware: IBM,9080-HEX POWER10 (sin procesar) 0x800200 0xf000006 de:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006b be5c LR : c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 No contaminado (6.7.0-203405+) MSR: 8000000000009033 CR: 2400 2220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Seguimiento de llamadas: iommu_init_device+0x26c/0x318 (no confiable) iommu_device_ enlace+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+ 0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_s can_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+ 0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b 0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+ 0x124/0x330 system_call_vectored_common+0x15c/0x2ec el commit a940904443e4 ("powerpc/iommu: agregue iommu_ops para informar capacidades y permitir dominios de bloqueo") rompió la adición DLPAR de dispositivos PCI. Lo anterior agregó la estructura iommu_device a pci_controller. • https://git.kernel.org/stable/c/a940904443e432623579245babe63e2486ff327b https://git.kernel.org/stable/c/b8315b2e25b4e68e42fcb74630f824b9a5067765 https://git.kernel.org/stable/c/46e36ebd5e00a148b67ed77c1d31675996f77c25 https://git.kernel.org/stable/c/a5c57fd2e9bd1c8ea8613a8f94fd0be5eccbf321 •
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 •