Page 48 of 2747 results (0.006 seconds)

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

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: 9EXPL: 0

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: 2EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/d1017d2a0f3f16dc1db5120e7ddbe7c6680425b0 https://git.kernel.org/stable/c/5ad6284c8d433f8a213111c5c44ead4d9705b622 https://git.kernel.org/stable/c/0338e66cba272351ca9d7d03f3628e390e70963b https://git.kernel.org/stable/c/ead82533278502428883085a787d5a00f15e5eb9 https://git.kernel.org/stable/c/6ce8b6ab44a8b5918c0ee373d4ad19d19017931b https://git.kernel.org/stable/c/c1ba4b8ca799ff1d99d01f37d7ccb7d5ba5533d2 https://git.kernel.org/stable/c/128d5cfdcf844cb690c9295a3a1c1114c •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled. • https://git.kernel.org/stable/c/5061b0c2b9066de426fbc63f1278d2210e789412 https://git.kernel.org/stable/c/07eb0bd7b0a8abed9d45e0f567c9af1dc83e5268 https://git.kernel.org/stable/c/04f75f5bae33349283d6886901d9acd2f110c024 https://git.kernel.org/stable/c/f232916fab67ca1c3425926df4a866e59ff26908 https://git.kernel.org/stable/c/acb53a716e492a02479345157c43f21edc8bc64b https://git.kernel.org/stable/c/db5ca4b42ccfa42d2af7b335ff12578e57775c02 https://git.kernel.org/stable/c/058c9026ad79dc98572442fd4c7e9a36aba6f596 https://git.kernel.org/stable/c/eab272972cffff9cd973b8e4055a8e81c •