Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Prevent CID stalls due to concurrent forks<br /> <br /> A newly forked task is accounted as MMCID user before the task is visible<br /> in the process&amp;#39; thread list and the global task list. This creates the<br /> following problem:<br /> <br /> CPU1 CPU2<br /> fork()<br /> sched_mm_cid_fork(tnew1)<br /> tnew1-&gt;mm.mm_cid_users++;<br /> tnew1-&gt;mm_cid.cid = getcid()<br /> -&gt; preemption<br /> fork()<br /> sched_mm_cid_fork(tnew2)<br /> tnew2-&gt;mm.mm_cid_users++;<br /> // Reaches the per CPU threshold<br /> mm_cid_fixup_tasks_to_cpus()<br /> for_each_other(current, p)<br /> ....<br /> <br /> As tnew1 is not visible yet, this fails to fix up the already allocated CID<br /> of tnew1. As a consequence a subsequent schedule in might fail to acquire a<br /> (transitional) CID and the machine stalls.<br /> <br /> Move the invocation of sched_mm_cid_fork() after the new task becomes<br /> visible in the thread and the task list to prevent this.<br /> <br /> This also makes it symmetrical vs. exit() where the task is removed as CID<br /> user before the task is removed from the thread and task lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix memory leaks in ceph_mdsc_build_path()<br /> <br /> Add __putname() calls to error code paths that did not free the "path"<br /> pointer obtained by __getname(). If ownership of this pointer is not<br /> passed to the caller via path_info.path, the function must free it<br /> before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix divide-by-zero in tipc_sk_filter_connect()<br /> <br /> A user can set conn_timeout to any value via<br /> setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a<br /> SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in<br /> tipc_sk_filter_connect() executes:<br /> <br /> delay %= (tsk-&gt;conn_timeout / 4);<br /> <br /> If conn_timeout is in the range [0, 3], the integer division yields 0,<br /> and the modulo operation triggers a divide-by-zero exception, causing a<br /> kernel oops/panic.<br /> <br /> Fix this by clamping conn_timeout to a minimum of 4 at the point of use<br /> in tipc_sk_filter_connect().<br /> <br /> Oops: divide error: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+<br /> RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362)<br /> Call Trace:<br /> tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406)<br /> __release_sock (include/net/sock.h:1185 net/core/sock.c:3213)<br /> release_sock (net/core/sock.c:3797)<br /> tipc_connect (net/tipc/socket.c:2570)<br /> __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled<br /> <br /> When the Remote System Update (RSU) isn&amp;#39;t enabled in the First Stage<br /> Boot Loader (FSBL), the driver encounters a NULL pointer dereference when<br /> excute svc_normal_to_secure_thread() thread, resulting in a kernel panic:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> Mem abort info:<br /> ...<br /> Data abort info:<br /> ...<br /> [0000000000000008] user address but active_mm is swapper<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 79 Comm: svc_smc_hvc_thr Not tainted 6.19.0-rc8-yocto-standard+ #59 PREEMPT<br /> Hardware name: SoCFPGA Stratix 10 SoCDK (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : svc_normal_to_secure_thread+0x38c/0x990<br /> lr : svc_normal_to_secure_thread+0x144/0x990<br /> ...<br /> Call trace:<br /> svc_normal_to_secure_thread+0x38c/0x990 (P)<br /> kthread+0x150/0x210<br /> ret_from_fork+0x10/0x20<br /> Code: 97cfc113 f9400260 aa1403e1 f9400400 (f9400402)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The issue occurs because rsu_send_async_msg() fails when RSU is not enabled<br /> in firmware, causing the channel to be freed via stratix10_svc_free_channel().<br /> However, the probe function continues execution and registers<br /> svc_normal_to_secure_thread(), which subsequently attempts to access the<br /> already-freed channel, triggering the NULL pointer dereference.<br /> <br /> Fix this by properly cleaning up the async client and returning early on<br /> failure, preventing the thread from being used with an invalid channel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes: avoid crash when rmmod/insmod after ftrace killed<br /> <br /> After we hit ftrace is killed by some errors, the kernel crash if<br /> we remove modules in which kprobe probes.<br /> <br /> BUG: unable to handle page fault for address: fffffbfff805000d<br /> PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP KASAN PTI<br /> CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OE<br /> Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> RIP: 0010:kprobes_module_callback+0x89/0x790<br /> RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02<br /> RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90<br /> RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a<br /> R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002<br /> R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040<br /> FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> notifier_call_chain+0xc6/0x280<br /> blocking_notifier_call_chain+0x60/0x90<br /> __do_sys_delete_module.constprop.0+0x32a/0x4e0<br /> do_syscall_64+0x5d/0xfa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> This is because the kprobe on ftrace does not correctly handles<br /> the kprobe_ftrace_disabled flag set by ftrace_kill().<br /> <br /> To prevent this error, check kprobe_ftrace_disabled in<br /> __disarm_kprobe_ftrace() and skip all ftrace related operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: add a bunch of missing ceph_path_info initializers<br /> <br /> ceph_mdsc_build_path() must be called with a zero-initialized<br /> ceph_path_info parameter, or else the following<br /> ceph_mdsc_free_path_info() may crash.<br /> <br /> Example crash (on Linux 6.18.12):<br /> <br /> virt_to_cache: Object is not a Slab page!<br /> WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmem_cache_free+0x316/0x400<br /> [...]<br /> Call Trace:<br /> [...]<br /> ceph_open+0x13d/0x3e0<br /> do_dentry_open+0x134/0x480<br /> vfs_open+0x2a/0xe0<br /> path_openat+0x9a3/0x1160<br /> [...]<br /> cache_from_obj: Wrong slab cache. names_cache but object is from ceph_inode_info<br /> WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmem_cache_free+0x2dd/0x400<br /> [...]<br /> kernel BUG at mm/slub.c:634!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> RIP: 0010:__slab_free+0x1a4/0x350<br /> <br /> Some of the ceph_mdsc_build_path() callers had initializers, but<br /> others had not, even though they were all added by commit 15f519e9f883<br /> ("ceph: fix race condition validating r_parent before applying state").<br /> The ones without initializer are suspectible to random crashes. (I can<br /> imagine it could even be possible to exploit this bug to elevate<br /> privileges.)<br /> <br /> Unfortunately, these Ceph functions are undocumented and its semantics<br /> can only be derived from the code. I see that ceph_mdsc_build_path()<br /> initializes the structure only on success, but not on error.<br /> <br /> Calling ceph_mdsc_free_path_info() after a failed<br /> ceph_mdsc_build_path() call does not even make sense, but that&amp;#39;s what<br /> all callers do, and for it to be safe, the structure must be<br /> zero-initialized. The least intrusive approach to fix this is<br /> therefore to add initializers everywhere.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()<br /> <br /> This patch fixes an out-of-bounds access in ceph_handle_auth_reply()<br /> that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In<br /> ceph_handle_auth_reply(), the value of the payload_len field of such a<br /> message is stored in a variable of type int. A value greater than<br /> INT_MAX leads to an integer overflow and is interpreted as a negative<br /> value. This leads to decrementing the pointer address by this value and<br /> subsequently accessing it because ceph_decode_need() only checks that<br /> the memory access does not exceed the end address of the allocation.<br /> <br /> This patch fixes the issue by changing the data type of payload_len to<br /> u32. Additionally, the data type of result_msg_len is changed to u32,<br /> as it is also a variable holding a non-negative length.<br /> <br /> Also, an additional layer of sanity checks is introduced, ensuring that<br /> directly after reading it from the message, payload_len and<br /> result_msg_len are not greater than the overall segment length.<br /> <br /> BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]<br /> Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262<br /> <br /> CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: ceph-msgr ceph_con_workfn [libceph]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x76/0xa0<br /> print_report+0xd1/0x620<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? kasan_complete_mode_report_info+0x72/0x210<br /> kasan_report+0xe7/0x130<br /> ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]<br /> ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]<br /> __asan_report_load_n_noabort+0xf/0x20<br /> ceph_handle_auth_reply+0x642/0x7a0 [libceph]<br /> mon_dispatch+0x973/0x23d0 [libceph]<br /> ? apparmor_socket_recvmsg+0x6b/0xa0<br /> ? __pfx_mon_dispatch+0x10/0x10 [libceph]<br /> ? __kasan_check_write+0x14/0x30i<br /> ? mutex_unlock+0x7f/0xd0<br /> ? __pfx_mutex_unlock+0x10/0x10<br /> ? __pfx_do_recvmsg+0x10/0x10 [libceph]<br /> ceph_con_process_message+0x1f1/0x650 [libceph]<br /> process_message+0x1e/0x450 [libceph]<br /> ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]<br /> ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph]<br /> ? save_fpregs_to_fpstate+0xb0/0x230<br /> ? raw_spin_rq_unlock+0x17/0xa0<br /> ? finish_task_switch.isra.0+0x13b/0x760<br /> ? __switch_to+0x385/0xda0<br /> ? __kasan_check_write+0x14/0x30<br /> ? mutex_lock+0x8d/0xe0<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ceph_con_workfn+0x248/0x10c0 [libceph]<br /> process_one_work+0x629/0xf80<br /> ? __kasan_check_write+0x14/0x30<br /> worker_thread+0x87f/0x1570<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx_try_to_wake_up+0x10/0x10<br /> ? kasan_print_address_stack_frame+0x1f7/0x280<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x396/0x830<br /> ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ? __kasan_check_write+0x14/0x30<br /> ? recalc_sigpending+0x180/0x210<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x3f7/0x610<br /> ? __pfx_ret_from_fork+0x10/0x10<br /> ? __switch_to+0x385/0xda0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> [ idryomov: replace if statements with ceph_decode_need() for<br /> payload_len and result_msg_len ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: prevent potential out-of-bounds reads in process_message_header()<br /> <br /> If the message frame is (maliciously) corrupted in a way that the<br /> length of the control segment ends up being less than the size of the<br /> message header or a different frame is made to look like a message<br /> frame, out-of-bounds reads may ensue in process_message_header().<br /> <br /> Perform an explicit bounds check before decoding the message header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Use u32 for non-negative values in ceph_monmap_decode()<br /> <br /> This patch fixes unnecessary implicit conversions that change signedness<br /> of blob_len and num_mon in ceph_monmap_decode().<br /> Currently blob_len and num_mon are (signed) int variables. They are used<br /> to hold values that are always non-negative and get assigned in<br /> ceph_decode_32_safe(), which is meant to assign u32 values. Both<br /> variables are subsequently used as unsigned values, and the value of<br /> num_mon is further assigned to monmap-&gt;num_mon, which is of type u32.<br /> Therefore, both variables should be of type u32. This is especially<br /> relevant for num_mon. If the value read from the incoming message is<br /> very large, it is interpreted as a negative value, and the check for<br /> num_mon &gt; CEPH_MAX_MON does not catch it. This leads to the attempt to<br /> allocate a very large chunk of memory for monmap, which will most likely<br /> fail. In this case, an unnecessary attempt to allocate memory is<br /> performed, and -ENOMEM is returned instead of -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: Fix a hmm_range_fault() livelock / starvation problem<br /> <br /> If hmm_range_fault() fails a folio_trylock() in do_swap_page,<br /> trying to acquire the lock of a device-private folio for migration,<br /> to ram, the function will spin until it succeeds grabbing the lock.<br /> <br /> However, if the process holding the lock is depending on a work<br /> item to be completed, which is scheduled on the same CPU as the<br /> spinning hmm_range_fault(), that work item might be starved and<br /> we end up in a livelock / starvation situation which is never<br /> resolved.<br /> <br /> This can happen, for example if the process holding the<br /> device-private folio lock is stuck in<br /> migrate_device_unmap()-&gt;lru_add_drain_all()<br /> sinc lru_add_drain_all() requires a short work-item<br /> to be run on all online cpus to complete.<br /> <br /> A prerequisite for this to happen is:<br /> a) Both zone device and system memory folios are considered in<br /> migrate_device_unmap(), so that there is a reason to call<br /> lru_add_drain_all() for a system memory folio while a<br /> folio lock is held on a zone device folio.<br /> b) The zone device folio has an initial mapcount &gt; 1 which causes<br /> at least one migration PTE entry insertion to be deferred to<br /> try_to_migrate(), which can happen after the call to<br /> lru_add_drain_all().<br /> c) No or voluntary only preemption.<br /> <br /> This all seems pretty unlikely to happen, but indeed is hit by<br /> the "xe_exec_system_allocator" igt test.<br /> <br /> Resolve this by waiting for the folio to be unlocked if the<br /> folio_trylock() fails in do_swap_page().<br /> <br /> Rename migration_entry_wait_on_locked() to<br /> softleaf_entry_wait_unlock() and update its documentation to<br /> indicate the new use-case.<br /> <br /> Future code improvements might consider moving<br /> the lru_add_drain_all() call in migrate_device_unmap() to be<br /> called *after* all pages have migration entries inserted.<br /> That would eliminate also b) above.<br /> <br /> v2:<br /> - Instead of a cond_resched() in hmm_range_fault(),<br /> eliminate the problem by waiting for the folio to be unlocked<br /> in do_swap_page() (Alistair Popple, Andrew Morton)<br /> v3:<br /> - Add a stub migration_entry_wait_on_locked() for the<br /> !CONFIG_MIGRATION case. (Kernel Test Robot)<br /> v4:<br /> - Rename migrate_entry_wait_on_locked() to<br /> softleaf_entry_wait_on_locked() and update docs (Alistair Popple)<br /> v5:<br /> - Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION<br /> version of softleaf_entry_wait_on_locked().<br /> - Modify wording around function names in the commit message<br /> (Andrew Morton)<br /> <br /> (cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nsfs: tighten permission checks for ns iteration ioctls<br /> <br /> Even privileged services should not necessarily be able to see other<br /> privileged service&amp;#39;s namespaces so they can&amp;#39;t leak information to each<br /> other. Use may_see_all_namespaces() helper that centralizes this policy<br /> until the nstree adapts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kthread: consolidate kthread exit paths to prevent use-after-free<br /> <br /> Guillaume reported crashes via corrupted RCU callback function pointers<br /> during KUnit testing. The crash was traced back to the pidfs rhashtable<br /> conversion which replaced the 24-byte rb_node with an 8-byte rhash_head<br /> in struct pid, shrinking it from 160 to 144 bytes.<br /> <br /> struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With<br /> CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to<br /> 192 bytes and share the same slab cache. struct pid.rcu.func and<br /> struct kthread.affinity_node both sit at offset 0x78.<br /> <br /> When a kthread exits via make_task_dead() it bypasses kthread_exit() and<br /> misses the affinity_node cleanup. free_kthread_struct() frees the memory<br /> while the node is still linked into the global kthread_affinity_list. A<br /> subsequent list_del() by another kthread writes through dangling list<br /> pointers into the freed and reused memory, corrupting the pid&amp;#39;s<br /> rcu.func pointer.<br /> <br /> Instead of patching free_kthread_struct() to handle the missed cleanup,<br /> consolidate all kthread exit paths. Turn kthread_exit() into a macro<br /> that calls do_exit() and add kthread_do_exit() which is called from<br /> do_exit() for any task with PF_KTHREAD set. This guarantees that<br /> kthread-specific cleanup always happens regardless of the exit path -<br /> make_task_dead(), direct do_exit(), or kthread_exit().<br /> <br /> Replace __to_kthread() with a new tsk_is_kthread() accessor in the<br /> public header. Export do_exit() since module code using the<br /> kthread_exit() macro now needs it directly.