CVSS: -EPSS: 0%CPEs: 9EXPL: 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/d1768e5535d3ded59f888637016e6f821f4e069f https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b 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/28f1cd94d3f1092728fb775a0fe26c5f1 •
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: 9EXPL: 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/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: 0CVE-2024-47713 – wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
https://notcve.org/view.php?id=CVE-2024-47713
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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47704 – drm/amd/display: Check link_res->hpo_dp_link_enc before using it
https://notcve.org/view.php?id=CVE-2024-47704
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. • https://git.kernel.org/stable/c/be2ca7a2c1561390d28bf2f92654d819659ba510 https://git.kernel.org/stable/c/530e29452b955c30cf2102fa4d07420dc6e0c953 https://git.kernel.org/stable/c/0508a4e95ac1aefd851ceb97ea050d8abb93262c https://git.kernel.org/stable/c/0beca868cde8742240cd0038141c30482d2b7eb8 •