Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Handle vfork()/CLONE_VM correctly<br /> <br /> Matthieu and Jiri reported stalls where a task endlessly loops in<br /> mm_get_cid() when scheduling in.<br /> <br /> It turned out that the logic which handles vfork()&amp;#39;ed tasks is broken. It<br /> is invoked when the number of tasks associated to a process is smaller than<br /> the number of MMCID users. It then walks the task list to find the<br /> vfork()&amp;#39;ed task, but accounts all the already processed tasks as well.<br /> <br /> If that double processing brings the number of to be handled tasks to 0,<br /> the walk stops and the vfork()&amp;#39;ed task&amp;#39;s CID is not fixed up. As a<br /> consequence a subsequent schedule in fails to acquire a (transitional) CID<br /> and the machine stalls.<br /> <br /> Cure this by removing the accounting condition and make the fixup always<br /> walk the full task list if it could not find the exact number of users in<br /> the process&amp;#39; thread list.

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 /> 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 /> 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: 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 /> 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 /> 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 /> 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 /> 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 /> drm/xe/sync: Fix user fence leak on alloc failure<br /> <br /> When dma_fence_chain_alloc() fails, properly release the user fence<br /> reference to prevent a memory leak.<br /> <br /> (cherry picked from commit a5d5634cde48a9fcd68c8504aa07f89f175074a0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: samsung-dsim: Fix memory leak in error path<br /> <br /> In samsung_dsim_host_attach(), drm_bridge_add() is called to add the<br /> bridge. However, if samsung_dsim_register_te_irq() or<br /> pdata-&gt;host_ops-&gt;attach() fails afterwards, the function returns<br /> without removing the bridge, causing a memory leak.<br /> <br /> Fix this by adding proper error handling with goto labels to ensure<br /> drm_bridge_remove() is called in all error paths. Also ensure that<br /> samsung_dsim_unregister_te_irq() is called if the attach operation<br /> fails after the TE IRQ has been registered.<br /> <br /> samsung_dsim_unregister_te_irq() function is moved without changes<br /> to be before samsung_dsim_host_attach() to avoid forward declaration.