Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix Route Information option length validation<br /> <br /> rt6_route_rcv() validates the Route Information option (RFC 4191) length<br /> against the prefix length, but both checks are off by one.<br /> <br /> rinfo-&gt;length is the ND option length in units of 8 octets and it<br /> *includes* the 8-byte option header, so an option carrying N bytes of<br /> prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3<br /> when Prefix Length is greater than 64, and 2 or 3 when it is greater<br /> than 0. The code accepts length &gt;= 2 and length &gt;= 1 respectively.<br /> <br /> ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo-&gt;prefix,<br /> so a Router Advertisement with (prefix_len=128, length=2) or<br /> (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the<br /> end of the option. Those bytes end up in the prefix of the route that<br /> gets installed, so they are visible to userspace:<br /> <br /> # RA with a Route Information option (prefix_len=128, length=2)<br /> # followed by a source link-layer address option, 01 01 de ad be ef ca fe<br /> $ ip -6 route show<br /> 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra<br /> ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds<br /> <br /> When the Route Information option is the last one in the packet, those<br /> eight bytes come from the skb tail room instead.<br /> <br /> Reject the option lengths RFC 4191 does not allow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: Fix board ID over-read<br /> <br /> The EEPROM board ID is a fixed 13-byte field and is not guaranteed to<br /> contain a NUL terminator. Passing it directly to<br /> devlink_info_version_fixed_put() treats it as a C string and may read<br /> beyond the field.<br /> <br /> Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer<br /> before reporting the ID. Use a precision limit because the snprintf()<br /> output size alone does not bound the source string scan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "thermal/drivers/hwmon: Cleanup coding style a bit"<br /> <br /> Revert commit 030a48b0f6ce ("thermal/drivers/hwmon: Cleanup coding style<br /> a bit") that introduced a use-after-free into the error path of<br /> thermal_add_hwmon_sysfs() by removing a valid check from it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventfs: Use children field for rcu head and add memory barriers<br /> <br /> When an eventfs inode is freed, it sets ei-&gt;is_freed and then uses its<br /> ei-&gt;list to add it to the srcu link list as the list field is a union with<br /> the rcu list head. As the ei-&gt;list is used to iterate over an SRCU<br /> protected list without taking the eventfs_mutex, there&amp;#39;s nothing stopping<br /> the iteration over that list to see the ei-&gt;rcu instead of the ei-&gt;list<br /> and it will read a corrupt target.<br /> <br /> To fix this, change the union of the rcu list head with the children list.<br /> On freeing the eventfs inode, set the is_free and execute a smp_wmb()<br /> before adding the eventfs inode to the SRCU list.<br /> <br /> On iteration of the ei-&gt;children list, at the start, execute a smp_rmb()<br /> and then read the is_freed of the ei to see if the children list is still<br /> valid. If is_freed is set, then the ei_child read is not valid and the<br /> loop should exit immediately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Take cgroup_lock() first in scx_cgroup_lock()<br /> <br /> scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes<br /> cgroup_lock(), which can deadlock through kernfs:<br /> <br /> scx enable/disable cgroup rmdir cpu.weight write<br /> ------------------ ------------ ----------------<br /> cgroup_lock()<br /> percpu_down_write(rwsem)<br /> cgroup_lock()<br /> kernfs_get_active()<br /> percpu_down_read(rwsem)<br /> kernfs_drain()<br /> <br /> The enable path waits for the rmdir to release cgroup_mutex. The rmdir,<br /> deactivating the cpu controller&amp;#39;s files, waits in kernfs_drain() for the<br /> write&amp;#39;s active reference. The write, in scx_group_set_weight(), waits for<br /> the rwsem behind the pending writer.<br /> <br /> Take cgroup_lock() first. The set_* paths take no cgroup locks inside the<br /> read side, so a pending write-lock then only waits for read sections that<br /> always run to completion, and no dependency from the rwsem back to<br /> cgroup_mutex remains.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: Shut down rtpoll_timer in psi_cgroup_free()<br /> <br /> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath<br /> and can race psi_trigger_destroy() taking down the last rtpoll trigger under<br /> rtpoll_trigger_lock:<br /> <br /> psi_schedule_rtpoll_work() psi_trigger_destroy()<br /> <br /> rcu_read_lock();<br /> task = rcu_dereference(rtpoll_task);<br /> rcu_assign_pointer(rtpoll_task, NULL);<br /> timer_delete(&amp;rtpoll_timer);<br /> mod_timer(&amp;rtpoll_timer, ...);<br /> rcu_read_unlock();<br /> synchronize_rcu();<br /> kthread_stop(task_to_destroy);<br /> <br /> The group can then be freed with the re-armed timer still pending, and<br /> poll_timer_fn() runs on freed memory.<br /> <br /> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling<br /> mechanism") deleted the timer synchronously after the synchronize_rcu(),<br /> which prevented this but raced trigger creation instead: the deletion could<br /> cancel the timer that a new trigger set armed during the grace period and,<br /> as creation also reinitialized the timer at the time, corrupt it.<br /> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the<br /> initialization into group_init() and the deletion into the locked section,<br /> trading the creation races for the window above.<br /> <br /> Neither placement in the destruction path works. A pending timer firing<br /> while the group is alive is harmless though. poll_timer_fn() just wakes the<br /> rtpoll waitqueue and doesn&amp;#39;t re-arm itself. Bind the timer to the group&amp;#39;s<br /> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it<br /> by then. timer_shutdown_sync() because the timer is never armed again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()<br /> <br /> fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with<br /> &amp;nop_mnt_idmap before allowing an encryption policy to be set, instead<br /> of the idmap of the mount the ioctl was issued on.<br /> <br /> fscrypt is used by filesystems that support idmapped mounts (e.g. ext4,<br /> f2fs), so on such a mount this compares the caller&amp;#39;s fsuid against the<br /> unmapped on-disk owner rather than the mapped owner: the actual owner<br /> can be wrongly denied with -EACCES and an unrelated caller wrongly<br /> allowed. Use file_mnt_idmap(filp) instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix sk_redir use-after-free in send verdict<br /> <br /> sk_psock_msg_verdict() takes a socket reference for psock-&gt;sk_redir.<br /> tcp_bpf_send_verdict() copies that pointer while holding the source socket<br /> lock, but does not take a reference for the local copy before dropping the<br /> lock around tcp_bpf_sendmsg_redir().<br /> <br /> When apply_bytes keeps the cached verdict active, another sendmsg() on the<br /> same source socket can consume the remaining bytes and release the cached<br /> reference while the first thread still holds only the raw local pointer:<br /> <br /> CPU 0 CPU 1<br /> sk_redir = psock-&gt;sk_redir<br /> apply_bytes remains nonzero<br /> release_sock(sk)<br /> lock_sock(sk)<br /> apply_bytes reaches zero<br /> psock-&gt;sk_redir = NULL<br /> release_sock(sk)<br /> tcp_bpf_sendmsg_redir(sk_redir)<br /> sock_put(sk_redir)<br /> tcp_bpf_sendmsg_redir(sk_redir)<br /> <br /> The final sock_put() can free sk_redir before CPU 0 dereferences it.<br /> <br /> KASAN reported:<br /> <br /> BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020<br /> Read of size 8 at addr ffff888108537090 by task poc/87<br /> Call Trace:<br /> tcp_bpf_sendmsg_redir+0xf39/0x1020<br /> tcp_bpf_sendmsg+0x977/0x1a50<br /> __sys_sendto+0x32c/0x3a0<br /> __x64_sys_sendto+0xdb/0x1b0<br /> Allocated by task 85:<br /> sk_prot_alloc+0x56/0x210<br /> sk_clone+0x6f/0x14b0<br /> inet_csk_clone_lock+0x24/0x740<br /> tcp_create_openreq_child+0x25/0x2710<br /> tcp_v4_syn_recv_sock+0x10a/0xe00<br /> Freed by task 0:<br /> __kasan_slab_free+0x43/0x70<br /> slab_free_after_rcu_debug+0xa6/0x1e0<br /> rcu_core+0x50a/0x1850<br /> Last potentially related work creation:<br /> __sk_destruct+0x3da/0x540<br /> sk_psock_destroy+0x81e/0xab0<br /> process_one_work+0x63a/0x1070<br /> <br /> Take a temporary socket reference while the source socket lock still<br /> protects psock-&gt;sk_redir, and drop it after tcp_bpf_sendmsg_redir()<br /> returns. This keeps each unlocked use independent of cached-verdict<br /> ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions<br /> <br /> The BPF verifier and the dynptr abstraction ensure that the memory space<br /> referenced by a dynptr remains valid. They do not, however, provide any<br /> guarantee that the contents of the memory are stable. kfuncs are<br /> expected to remain memory-safe even if concurrent modifications occur.<br /> <br /> bpf_get_fsverity_digest() didn&amp;#39;t follow that: it could crash if<br /> arg-&gt;digest_size was concurrently modified.<br /> <br /> Fix that by using the known-good value hash_alg-&gt;digest_size instead.<br /> <br /> Also widen &amp;#39;dynptr_sz&amp;#39; and &amp;#39;out_digest_sz&amp;#39; to u64 to match the return<br /> type of __bpf_dynptr_size(). It doesn&amp;#39;t appear that it can actually be<br /> more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes<br /> file-based pointers), but the correct type might as well be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: __filemap_add_folio() restore index before retrying<br /> <br /> In __filemap_add_folio()&amp;#39;s split-a-conflict loop, xas_set_order() is<br /> applied repeatedly: each application modifies xas.xa_index, rounding it<br /> down according to the split_order attempted at that stage: and if all goes<br /> as intended, it eventually (or immediately) converges on an<br /> xas_try_split() to the required folio_order, with xas.xa_index now the<br /> same as index: then xas_store() puts the new folio into the xarray there.<br /> <br /> But if a new node was needed, and GFP_NOWAIT allocation did not get one,<br /> the lock is dropped, xas_nomem() used to allocate, and sequence retried. <br /> If (that part of) the xarray is unchanged when the lock is reacquired, no<br /> problem. But what if the conflict was meanwhile resolved by another<br /> thread (perhaps even doing the same thing, inserting a folio at that same<br /> index)? Isn&amp;#39;t there a danger of now putting our folio into the xarray at<br /> an intermediate rounded-down index? With !folio_contains() bug to follow,<br /> when CONFIG_DEBUG_VM=y is checking for that.<br /> <br /> Fix this with an xas_set_order() to restore the original xas.xa_index at<br /> the bottom of the loop, so the retry does a full re-evaluation after<br /> reacquiring the lock, and cannot reach xas_store() with the wrong index.<br /> <br /> Production was suffering from rare SIGILLs and SIGSEGVs, executable text<br /> found a page away from where it belonged, !folio_contains() bug hit when<br /> debug enabled: symptoms not seen since this patch went in.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Instantiate file_truncate and path_truncate hooks<br /> <br /> Instantiate the file_truncate and path_truncate LSM hooks to reset the<br /> action cache flags (IMA_DONE_MASK) as soon as truncation is requested,<br /> so the file, based on policy, is re-collected, re-measured, re-audited,<br /> and re-appraised on next access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs,fsverity: remove check for fsverity being enabled in setattr_prepare()<br /> <br /> The check that fs-verity is available in the kernel is not necessary<br /> here. Filesystems could have fsverity files even without fs-verity<br /> enabled. In that case, truncate on fsverity file will succeed, what this<br /> check is trying to prevent.