CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47742 – firmware_loader: Block path traversal
https://notcve.org/view.php?id=CVE-2024-47742
In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. • https://git.kernel.org/stable/c/abb139e75c2cdbb955e840d6331cb5863e409d0e https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4 https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251 https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4 https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec0 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/f3bfac2cabf5333506b263bc0c8497c95302f32d https://git.kernel.org/stable/c/4583290898c13c2c2e5eb8773886d153c2c5121d https://git.kernel.org/stable/c/4f5a100f87f32cb65d4bb1ad282a08c92 •
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: 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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47723 – jfs: fix out-of-bounds in dbNextAG() and diAlloc()
https://notcve.org/view.php?id=CVE-2024-47723
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/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/128d5cfdcf844cb690c9295a3a1c1114c21fc15a https://git.kernel.org/stable/c/96855f40e152989c9e7c20c4691ace5581098acc https://git.kernel.org/stable/c/e63866a475562810500ea7f784099bfe3 •