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: 3EXPL: 0CVE-2024-47736 – erofs: handle overlapped pclusters out of crafted images properly
https://notcve.org/view.php?id=CVE-2024-47736
In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference. • https://git.kernel.org/stable/c/8e6c8fa9f2e95c88a642521a5da19a8e31748846 https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8 https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50 •