CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47739 – padata: use integer wrap around to prevent deadlock on seq_nr overflow
https://notcve.org/view.php?id=CVE-2024-47739
In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow. • https://git.kernel.org/stable/c/bfde23ce200e6d33291d29b9b8b60cc2f30f0805 https://git.kernel.org/stable/c/46c4079460f4dcaf445860679558eedef4e1bc91 https://git.kernel.org/stable/c/72164d5b648951684b1a593996b37a6083c61d7d https://git.kernel.org/stable/c/ab205e1c3846326f162180e56825b4ba38ce9c30 https://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428 https://git.kernel.org/stable/c/9e279e6c1f012b82628b89e1b9c65dbefa8ca25a https://git.kernel.org/stable/c/1bd712de96ad7167fe0d608e706cd60587579f16 https://git.kernel.org/stable/c/9a22b2812393d93d84358a760c347c219 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47737 – nfsd: call cache_put if xdr_reserve_space returns NULL
https://notcve.org/view.php?id=CVE-2024-47737
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org> • https://git.kernel.org/stable/c/ddd1ea56367202f6c99135cd59de7a97af4c4ffd https://git.kernel.org/stable/c/9f03f0016ff797932551881c7e06ae50e9c39134 https://git.kernel.org/stable/c/9803ab882d565a8fb2dde5999d98866d1c499dfd https://git.kernel.org/stable/c/81821617312988096f5deccf0f7da6f888e98056 https://git.kernel.org/stable/c/a1afbbb5276f943ad7173d0b4c626b8c75a260da https://git.kernel.org/stable/c/e32ee6a61041925d1a05c14d10352dcfce9ef029 https://git.kernel.org/stable/c/8d0765f86135e27f0bb5c950c136495719b4c834 https://git.kernel.org/stable/c/d078cbf5c38de83bc31f83c47dcd2184c •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47735 – RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled
https://notcve.org/view.php?id=CVE-2024-47735
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2] • https://git.kernel.org/stable/c/9a4435375cd151e07c0c38fa601b00115986091b https://git.kernel.org/stable/c/07f0f643d7e570dbe8ef6f5c3367a43e3086a335 https://git.kernel.org/stable/c/29c0f546d3fd66238b42cf25bcd5f193bb1cf794 https://git.kernel.org/stable/c/425589d4af09c49574bd71ac31f811362a5126c3 https://git.kernel.org/stable/c/094a1821903f33fb91de4b71087773ee16aeb3a0 https://git.kernel.org/stable/c/2656336a84fcb6802f6e6c233f4661891deea24f https://git.kernel.org/stable/c/a1a3403bb1826c8ec787f0d60c3e7b54f419129e https://git.kernel.org/stable/c/74d315b5af180220d561684d158977301 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47728 – bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
https://notcve.org/view.php?id=CVE-2024-47728
In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. • https://git.kernel.org/stable/c/d7a4cb9b6705a89937d12c8158a35a3145dc967a https://git.kernel.org/stable/c/8397bf78988f3ae9dbebb0200189a62a57264980 https://git.kernel.org/stable/c/a634fa8e480ac2423f86311a602f6295df2c8ed0 https://git.kernel.org/stable/c/599d15b6d03356a97bff7a76155c5604c42a2962 https://git.kernel.org/stable/c/594a9f5a8d2de2573a856e506f77ba7dd2cefc6a https://git.kernel.org/stable/c/4b3786a6c5397dc220b1483d8e2f4867743e966f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47726 – f2fs: fix to wait dio completion
https://notcve.org/view.php?id=CVE-2024-47726
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode. • https://git.kernel.org/stable/c/e3db757ff9b7101ae68650ac5f6dd5743b68164e https://git.kernel.org/stable/c/96cfeb0389530ae32ade8a48ae3ae1ac3b6c009d •