Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cxgb4: Added NULL check for lookup_atid<br /> <br /> The lookup_atid() function can return NULL if the ATID is<br /> invalid or does not exist in the identifier table, which<br /> could lead to dereferencing a null pointer without a<br /> check in the `act_establish()` and `act_open_rpl()` functions.<br /> Add a NULL check to prevent null pointer dereferencing.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition<br /> <br /> In the ether3_probe function, a timer is initialized with a callback<br /> function ether3_ledoff, bound to &amp;prev(dev)-&gt;timer. Once the timer is<br /> started, there is a risk of a race condition if the module or device<br /> is removed, triggering the ether3_remove function to perform cleanup.<br /> The sequence of operations that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | ether3_ledoff<br /> ether3_remove |<br /> free_netdev(dev); |<br /> put_devic |<br /> kfree(dev); |<br /> | ether3_outw(priv(dev)-&gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2);<br /> | // use dev<br /> <br /> Fix it by ensuring that the timer is canceled before proceeding with<br /> the cleanup in ether3_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Block path traversal<br /> <br /> Most firmware names are hardcoded strings, or are constructed from fairly<br /> constrained format strings where the dynamic parts are just some hex<br /> numbers or such.<br /> <br /> However, there are a couple codepaths in the kernel where firmware file<br /> names contain string components that are passed through from a device or<br /> semi-privileged userspace; the ones I could find (not counting interfaces<br /> that require root privileges) are:<br /> <br /> - lpfc_sli4_request_firmware_update() seems to construct the firmware<br /> filename from "ModelName", a string that was previously parsed out of<br /> some descriptor ("Vital Product Data") in lpfc_fill_vpd()<br /> - nfp_net_fw_find() seems to construct a firmware filename from a model<br /> name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, "nffw.partno"), which I<br /> think parses some descriptor that was read from the device.<br /> (But this case likely isn&amp;#39;t exploitable because the format string looks<br /> like "netronome/nic_%s", and there shouldn&amp;#39;t be any *folders* starting<br /> with "netronome/nic_". The previous case was different because there,<br /> the "%s" is *at the start* of the format string.)<br /> - module_flash_fw_schedule() is reachable from the<br /> ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as<br /> GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is<br /> enough to pass the privilege check), and takes a userspace-provided<br /> firmware name.<br /> (But I think to reach this case, you need to have CAP_NET_ADMIN over a<br /> network namespace that a special kind of ethernet device is mapped into,<br /> so I think this is not a viable attack path in practice.)<br /> <br /> Fix it by rejecting any firmware names containing ".." path components.<br /> <br /> For what it&amp;#39;s worth, I went looking and haven&amp;#39;t found any USB device<br /> drivers that use the firmware loader dangerously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: call the security_mmap_file() LSM hook in remap_file_pages()<br /> <br /> The remap_file_pages syscall handler calls do_mmap() directly, which<br /> doesn&amp;#39;t contain the LSM security check. And if the process has called<br /> personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for<br /> RW pages, this will actually result in remapping the pages to RWX,<br /> bypassing a W^X policy enforced by SELinux.<br /> <br /> So we should check prot by security_mmap_file LSM hook in the<br /> remap_file_pages syscall handler before do_mmap() is called. Otherwise, it<br /> potentially permits an attacker to bypass a W^X policy enforced by<br /> SELinux.<br /> <br /> The bypass is similar to CVE-2016-10044, which bypass the same thing via<br /> AIO and can be found in [1].<br /> <br /> The PoC:<br /> <br /> $ cat &gt; test.c<br /> <br /> int main(void) {<br /> size_t pagesz = sysconf(_SC_PAGE_SIZE);<br /> int mfd = syscall(SYS_memfd_create, "test", 0);<br /> const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,<br /> MAP_SHARED, mfd, 0);<br /> unsigned int old = syscall(SYS_personality, 0xffffffff);<br /> syscall(SYS_personality, READ_IMPLIES_EXEC | old);<br /> syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);<br /> syscall(SYS_personality, old);<br /> // show the RWX page exists even if W^X policy is enforced<br /> int fd = open("/proc/self/maps", O_RDONLY);<br /> unsigned char buf2[1024];<br /> while (1) {<br /> int ret = read(fd, buf2, 1024);<br /> if (ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Use reserved copy engine for user binds on faulting devices<br /> <br /> User binds map to engines with can fault, faults depend on user binds<br /> completion, thus we can deadlock. Avoid this by using reserved copy<br /> engine for user binds on faulting devices.<br /> <br /> While we are here, normalize bind queue creation with a helper.<br /> <br /> v2:<br /> - Pass in extensions to bind queue creation (CI)<br /> v3:<br /> - s/resevered/reserved (Lucas)<br /> - Fix NULL hwe check (Jonathan)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - Fix potential use after free bug<br /> <br /> The free_device_compression_mode(iaa_device, device_mode) function frees<br /> "device_mode" but it iss passed to iaa_compression_modes[i]-&gt;free() a few<br /> lines later resulting in a use after free.<br /> <br /> The good news is that, so far as I can tell, nothing implements the<br /> -&gt;free() function and the use after free happens in dead code. But, with<br /> this fix, when something does implement it, we&amp;#39;ll be ready. :)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Delete subtree of &amp;#39;fs/netfs&amp;#39; when netfs module exits<br /> <br /> In netfs_init() or fscache_proc_init(), we create dentry under &amp;#39;fs/netfs&amp;#39;,<br /> but in netfs_exit(), we only delete the proc entry of &amp;#39;fs/netfs&amp;#39; without<br /> deleting its subtree. This triggers the following WARNING:<br /> <br /> ==================================================================<br /> remove_proc_entry: removing non-empty directory &amp;#39;fs/netfs&amp;#39;, leaking at least &amp;#39;requests&amp;#39;<br /> WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0<br /> Modules linked in: netfs(-)<br /> CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860<br /> RIP: 0010:remove_proc_entry+0x160/0x1c0<br /> Call Trace:<br /> <br /> netfs_exit+0x12/0x620 [netfs]<br /> __do_sys_delete_module.isra.0+0x14c/0x2e0<br /> do_syscall_64+0x4b/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ==================================================================<br /> <br /> Therefore use remove_proc_subtree() instead of remove_proc_entry() to<br /> fix the above problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: Fix ali_drw_pmu driver interrupt status clearing<br /> <br /> The alibaba_uncore_pmu driver forgot to clear all interrupt status<br /> in the interrupt processing function. After the PMU counter overflow<br /> interrupt occurred, an interrupt storm occurred, causing the system<br /> to hang.<br /> <br /> Therefore, clear the correct interrupt status in the interrupt handling<br /> function to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()<br /> <br /> syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce<br /> this[1], one bond device (bond1) has xdpdrv, which increases<br /> bpf_master_redirect_enabled_key. Another bond device (bond0) which is<br /> unsupported by XDP but its slave (veth3) has xdpgeneric that returns<br /> XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect().<br /> To reduce unnecessary warnings and improve log management, we need to<br /> delete the WARN_ON_ONCE() and add ratelimit to the netdev_err().<br /> <br /> [1] Steps to reproduce:<br /> # Needs tx_xdp with return XDP_TX;<br /> ip l add veth0 type veth peer veth1<br /> ip l add veth3 type veth peer veth4<br /> ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP<br /> ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default<br /> ip l set veth0 master bond1<br /> ip l set bond1 up<br /> # Increases bpf_master_redirect_enabled_key<br /> ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx<br /> ip l set veth3 master bond0<br /> ip l set bond0 up<br /> ip l set veth4 up<br /> # Triggers WARN_ON_ONCE() from the xdp_master_redirect()<br /> ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: don&amp;#39;t use rate mask for offchannel TX either<br /> <br /> Like the commit ab9177d83c04 ("wifi: mac80211: don&amp;#39;t use rate mask for<br /> scanning"), ignore incorrect settings to avoid no supported rate warning<br /> reported by syzbot.<br /> <br /> The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:<br /> fix default HE tx bitrate mask in 2G band"), which however corrects<br /> bitmask of HE MCS and recognizes correctly settings of empty legacy rate<br /> plus HE MCS rate instead of returning -EINVAL.<br /> <br /> As suggestions [1], follow the change of SCAN TX to consider this case of<br /> offchannel TX as well.<br /> <br /> [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled<br /> <br /> Fix missuse of spin_lock_irq()/spin_unlock_irq() when<br /> spin_lock_irqsave()/spin_lock_irqrestore() was hold.<br /> <br /> This was discovered through the lock debugging, and the corresponding<br /> log is as follows:<br /> <br /> raw_local_irq_restore() called with IRQs enabled<br /> WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40<br /> ...<br /> Call trace:<br /> warn_bogus_irq_restore+0x30/0x40<br /> _raw_spin_unlock_irqrestore+0x84/0xc8<br /> add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]<br /> hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]<br /> hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]<br /> create_qp+0x138/0x258<br /> ib_create_qp_kernel+0x50/0xe8<br /> create_mad_qp+0xa8/0x128<br /> ib_mad_port_open+0x218/0x448<br /> ib_mad_init_device+0x70/0x1f8<br /> add_client_context+0xfc/0x220<br /> enable_device_and_get+0xd0/0x140<br /> ib_register_device.part.0+0xf4/0x1c8<br /> ib_register_device+0x34/0x50<br /> hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]<br /> hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]<br /> __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]<br /> hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]