CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47740 – f2fs: Require FMODE_WRITE for atomic write ioctls
https://notcve.org/view.php?id=CVE-2024-47740
In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. • https://git.kernel.org/stable/c/88b88a66797159949cec32eaab12b4968f6fae2d https://git.kernel.org/stable/c/700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653 https://git.kernel.org/stable/c/4ce87674c3a6b4d3b3d45f85b584ab8618a3cece https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac https://git.kernel.org/stable/c/88ff021e1fea2d9b40b2d5efd9013c89f7be04ac https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713 https://git.kernel.org/stable/c/5e0de753bfe87768ebe6744d869caa92f35e5731 https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95 •
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: 8EXPL: 0CVE-2024-47738 – wifi: mac80211: don't use rate mask for offchannel TX either
https://notcve.org/view.php?id=CVE-2024-47738
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 • https://git.kernel.org/stable/c/9df66d5b9f45c39b3925d16e8947cc10009b186d https://git.kernel.org/stable/c/1b728869a13470e4c25e8faf0dbb95a009c6850b https://git.kernel.org/stable/c/ccedf8163fa66f2db85d863a43f056ac69a5fef5 https://git.kernel.org/stable/c/5924678a442d0f5ebf33ebb76b470e68414f1318 https://git.kernel.org/stable/c/aafca50e71dc8f3192a5bfb325135a7908f3ef9e https://git.kernel.org/stable/c/d54455a3a965feb547711aff7afd2ca5deadb99c https://git.kernel.org/stable/c/3565ef215101ffadb5fe5394c70b1fca51376b25 https://git.kernel.org/stable/c/43897111481b679508711d3ca881c4c65 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/3e8081ebff12bec1347deaceb6bce0765cce54df https://git.kernel.org/stable/c/c6b16e700cf4d959af524bd9d3978407ff7ce462 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/e32ee6a61041925d1a05c14d10352dcfc •
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 •