Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set<br /> <br /> This may be a typo. The comment has said shared locks are<br /> not allowed when this bit is set. If using shared lock, the<br /> wait in `fuse_file_cached_io_open` may be forever.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: use integer wrap around to prevent deadlock on seq_nr overflow<br /> <br /> When submitting more than 2^32 padata objects to padata_do_serial, the<br /> current sorting implementation incorrectly sorts padata objects with<br /> overflowed seq_nr, causing them to be placed before existing objects in<br /> the reorder list. This leads to a deadlock in the serialization process<br /> as padata_find_next cannot match padata-&gt;seq_nr and pd-&gt;processed<br /> because the padata instance with overflowed seq_nr will be selected<br /> next.<br /> <br /> To fix this, we use an unsigned integer wrap around to correctly sort<br /> padata objects in scenarios with integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: Require FMODE_WRITE for atomic write ioctls<br /> <br /> The F2FS ioctls for starting and committing atomic writes check for<br /> inode_owner_or_capable(), but this does not give LSMs like SELinux or<br /> Landlock an opportunity to deny the write access - if the caller&amp;#39;s FSUID<br /> matches the inode&amp;#39;s UID, inode_owner_or_capable() immediately returns true.<br /> <br /> There are scenarios where LSMs want to deny a process the ability to write<br /> particular files, even files that the FSUID of the process owns; but this<br /> can currently partially be bypassed using atomic write ioctls in two ways:<br /> <br /> - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can<br /> truncate an inode to size 0<br /> - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert<br /> changes another process concurrently made to a file<br /> <br /> Fix it by requiring FMODE_WRITE for these operations, just like for<br /> F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these<br /> ioctls when intending to write into the file, that seems unlikely to break<br /> anything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: prevent NULL pointer dereference in find_asymmetric_key()<br /> <br /> In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2}<br /> arguments, the kernel will first emit WARN but then have an oops<br /> because id_2 gets dereferenced anyway.<br /> <br /> Add the missing id_2 check and move WARN_ON() to the final else branch<br /> to avoid duplicate NULL checks.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_vdpa: assign irq bypass producer token correctly<br /> <br /> We used to call irq_bypass_unregister_producer() in<br /> vhost_vdpa_setup_vq_irq() which is problematic as we don&amp;#39;t know if the<br /> token pointer is still valid or not.<br /> <br /> Actually, we use the eventfd_ctx as the token so the life cycle of the<br /> token should be bound to the VHOST_SET_VRING_CALL instead of<br /> vhost_vdpa_setup_vq_irq() which could be called by set_status().<br /> <br /> Fixing this by setting up irq bypass producer&amp;#39;s token when handling<br /> VHOST_SET_VRING_CALL and un-registering the producer before calling<br /> vhost_vring_ioctl() to prevent a possible use after free as eventfd<br /> could have been released in vhost_vring_ioctl(). And such registering<br /> and unregistering will only be done if DRIVER_OK is set.

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.