Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hung_task: fix warnings caused by unaligned lock pointers<br /> <br /> The blocker tracking mechanism assumes that lock pointers are at least<br /> 4-byte aligned to use their lower bits for type encoding.<br /> <br /> However, as reported by Eero Tamminen, some architectures like m68k<br /> only guarantee 2-byte alignment of 32-bit values. This breaks the<br /> assumption and causes two related WARN_ON_ONCE checks to trigger.<br /> <br /> To fix this, the runtime checks are adjusted to silently ignore any lock<br /> that is not 4-byte aligned, effectively disabling the feature in such<br /> cases and avoiding the related warnings.<br /> <br /> Thanks to Geert Uytterhoeven for bisecting!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: avoid infinite loops due to corrupted subpage compact indexes<br /> <br /> Robert reported an infinite loop observed by two crafted images.<br /> <br /> The root cause is that `clusterofs` can be larger than `lclustersize`<br /> for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:<br /> <br /> blocksize = lclustersize = 512 lcn = 6 clusterofs = 515<br /> <br /> Move the corresponding check for full compress indexes to<br /> `z_erofs_load_lcluster_from_disk()` to also cover subpage compact<br /> compress indexes.<br /> <br /> It also fixes the position of `m-&gt;type &gt;= Z_EROFS_LCLUSTER_TYPE_MAX`<br /> check, since it should be placed right after<br /> `z_erofs_load_{compact,full}_lcluster()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup<br /> <br /> In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to<br /> the dma_buf for comparison purposes. However, this reference is never<br /> released when the function returns, leading to a dma_buf memory leak.<br /> <br /> Fix this by adding dma_buf_put before returning from the function,<br /> ensuring that the temporarily acquired reference is properly released<br /> regardless of whether a matching map is found.<br /> <br /> Rule: add

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: don&amp;#39;t spin in add_stack_record when gfp flags don&amp;#39;t allow<br /> <br /> syzbot was able to find the following path:<br /> add_stack_record_to_list mm/page_owner.c:182 [inline]<br /> inc_stack_record_count mm/page_owner.c:214 [inline]<br /> __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851<br /> prep_new_page mm/page_alloc.c:1859 [inline]<br /> get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858<br /> alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554<br /> <br /> Don&amp;#39;t spin in add_stack_record_to_list() when it is called<br /> from *_nolock() context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing<br /> <br /> The Extended Supported Rates (ESR) IE handling in OnBeacon accessed<br /> *(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these<br /> offsets lie within the received frame buffer. A malformed beacon with<br /> an ESR IE positioned at the end of the buffer could cause an<br /> out-of-bounds read, potentially triggering a kernel panic.<br /> <br /> Add a boundary check to ensure that the ESR IE body and the subsequent<br /> bytes are within the limits of the frame before attempting to access<br /> them.<br /> <br /> This prevents OOB reads caused by malformed beacon frames.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing<br /> <br /> The Supported Rates IE length from an incoming Association Request frame<br /> was used directly as the memcpy() length when copying into a fixed-size<br /> 16-byte stack buffer (supportRate). A malicious station can advertise an<br /> IE length larger than 16 bytes, causing a stack buffer overflow.<br /> <br /> Clamp ie_len to the buffer size before copying the Supported Rates IE,<br /> and correct the bounds check when merging Extended Supported Rates to<br /> prevent a second potential overflow.<br /> <br /> This prevents kernel stack corruption triggered by malformed association<br /> requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: restore write access before closing files opened by open_exec()<br /> <br /> bm_register_write() opens an executable file using open_exec(), which<br /> internally calls do_open_execat() and denies write access on the file to<br /> avoid modification while it is being executed.<br /> <br /> However, when an error occurs, bm_register_write() closes the file using<br /> filp_close() directly. This does not restore the write permission, which<br /> may cause subsequent write operations on the same file to fail.<br /> <br /> Fix this by calling exe_file_allow_write_access() before filp_close() to<br /> restore the write permission properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: avoid having an active sc_timer before freeing sci<br /> <br /> Because kthread_stop did not stop sc_task properly and returned -EINTR,<br /> the sc_timer was not properly closed, ultimately causing the problem [1]<br /> reported by syzbot when freeing sci due to the sc_timer not being closed.<br /> <br /> Because the thread sc_task main function nilfs_segctor_thread() returns 0<br /> when it succeeds, when the return value of kthread_stop() is not 0 in<br /> nilfs_segctor_destroy(), we believe that it has not properly closed<br /> sc_timer.<br /> <br /> We use timer_shutdown_sync() to sync wait for sc_timer to shutdown, and<br /> set the value of sc_task to NULL under the protection of lock<br /> sc_state_lock, so as to avoid the issue caused by sc_timer not being<br /> properly shutdowned.<br /> <br /> [1]<br /> ODEBUG: free active (active state 0) object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout<br /> Call trace:<br /> nilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline]<br /> nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c:2877<br /> nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe<br /> <br /> The sit driver&amp;#39;s packet transmission path calls: sit_tunnel_xmit() -&gt;<br /> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called<br /> to delete entries exceeding FNHE_RECLAIM_DEPTH+random.<br /> <br /> The race window is between fnhe_remove_oldest() selecting fnheX for<br /> deletion and the subsequent kfree_rcu(). During this time, the<br /> concurrent path&amp;#39;s __mkroute_output() -&gt; find_exception() can fetch the<br /> soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a<br /> new dst using a dst_hold(). When the original fnheX is freed via RCU,<br /> the dst reference remains permanently leaked.<br /> <br /> CPU 0 CPU 1<br /> __mkroute_output()<br /> find_exception() [fnheX]<br /> update_or_create_fnhe()<br /> fnhe_remove_oldest() [fnheX]<br /> rt_bind_exception() [bind dst]<br /> RCU callback [fnheX freed, dst leak]<br /> <br /> This issue manifests as a device reference count leak and a warning in<br /> dmesg when unregistering the net device:<br /> <br /> unregister_netdevice: waiting for sitX to become free. Usage count = N<br /> <br /> Ido Schimmel provided the simple test validation method [1].<br /> <br /> The fix clears &amp;#39;oldest-&gt;fnhe_daddr&amp;#39; before calling fnhe_flush_routes().<br /> Since rt_bind_exception() checks this field, setting it to zero prevents<br /> the stale fnhe from being reused and bound to a new dst just before it<br /> is freed.<br /> <br /> [1]<br /> ip netns add ns1<br /> ip -n ns1 link set dev lo up<br /> ip -n ns1 address add 192.0.2.1/32 dev lo<br /> ip -n ns1 link add name dummy1 up type dummy<br /> ip -n ns1 route add 192.0.2.2/32 dev dummy1<br /> ip -n ns1 link add name gretap1 up arp off type gretap \<br /> local 192.0.2.1 remote 192.0.2.2<br /> ip -n ns1 route add 198.51.0.0/16 dev gretap1<br /> taskset -c 0 ip netns exec ns1 mausezahn gretap1 \<br /> -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &amp;<br /> taskset -c 2 ip netns exec ns1 mausezahn gretap1 \<br /> -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &amp;<br /> sleep 10<br /> ip netns pids ns1 | xargs kill<br /> ip netns del ns1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix LTP test failures when timestamps are delegated<br /> <br /> The utimes01 and utime06 tests fail when delegated timestamps are<br /> enabled, specifically in subtests that modify the atime and mtime<br /> fields using the &amp;#39;nobody&amp;#39; user ID.<br /> <br /> The problem can be reproduced as follow:<br /> <br /> # echo "/media *(rw,no_root_squash,sync)" &gt;&gt; /etc/exports<br /> # export -ra<br /> # mount -o rw,nfsvers=4.2 127.0.0.1:/media /tmpdir<br /> # cd /opt/ltp<br /> # ./runltp -d /tmpdir -s utimes01<br /> # ./runltp -d /tmpdir -s utime06<br /> <br /> This issue occurs because nfs_setattr does not verify the inode&amp;#39;s<br /> UID against the caller&amp;#39;s fsuid when delegated timestamps are<br /> permitted for the inode.<br /> <br /> This patch adds the UID check and if it does not match then the<br /> request is sent to the server for permission checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Check the TLS certificate fields in nfs_match_client()<br /> <br /> If the TLS security policy is of type RPC_XPRTSEC_TLS_X509, then the<br /> cert_serial and privkey_serial fields need to match as well since they<br /> define the client&amp;#39;s identity, as presented to the server.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD<br /> <br /> On completion of i915_vma_pin_ww(), a synchronous variant of<br /> dma_fence_work_commit() is called. When pinning a VMA to GGTT address<br /> space on a Cherry View family processor, or on a Broxton generation SoC<br /> with VTD enabled, i.e., when stop_machine() is then called from<br /> intel_ggtt_bind_vma(), that can potentially lead to lock inversion among<br /> reservation_ww and cpu_hotplug locks.<br /> <br /> [86.861179] ======================================================<br /> [86.861193] WARNING: possible circular locking dependency detected<br /> [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U<br /> [86.861226] ------------------------------------------------------<br /> [86.861238] i915_module_loa/1432 is trying to acquire lock:<br /> [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50<br /> [86.861290]<br /> but task is already holding lock:<br /> [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915]<br /> [86.862233]<br /> which lock already depends on the new lock.<br /> [86.862251]<br /> the existing dependency chain (in reverse order) is:<br /> [86.862265]<br /> -&gt; #5 (reservation_ww_class_mutex){+.+.}-{3:3}:<br /> [86.862292] dma_resv_lockdep+0x19a/0x390<br /> [86.862315] do_one_initcall+0x60/0x3f0<br /> [86.862334] kernel_init_freeable+0x3cd/0x680<br /> [86.862353] kernel_init+0x1b/0x200<br /> [86.862369] ret_from_fork+0x47/0x70<br /> [86.862383] ret_from_fork_asm+0x1a/0x30<br /> [86.862399]<br /> -&gt; #4 (reservation_ww_class_acquire){+.+.}-{0:0}:<br /> [86.862425] dma_resv_lockdep+0x178/0x390<br /> [86.862440] do_one_initcall+0x60/0x3f0<br /> [86.862454] kernel_init_freeable+0x3cd/0x680<br /> [86.862470] kernel_init+0x1b/0x200<br /> [86.862482] ret_from_fork+0x47/0x70<br /> [86.862495] ret_from_fork_asm+0x1a/0x30<br /> [86.862509]<br /> -&gt; #3 (&amp;mm-&gt;mmap_lock){++++}-{3:3}:<br /> [86.862531] down_read_killable+0x46/0x1e0<br /> [86.862546] lock_mm_and_find_vma+0xa2/0x280<br /> [86.862561] do_user_addr_fault+0x266/0x8e0<br /> [86.862578] exc_page_fault+0x8a/0x2f0<br /> [86.862593] asm_exc_page_fault+0x27/0x30<br /> [86.862607] filldir64+0xeb/0x180<br /> [86.862620] kernfs_fop_readdir+0x118/0x480<br /> [86.862635] iterate_dir+0xcf/0x2b0<br /> [86.862648] __x64_sys_getdents64+0x84/0x140<br /> [86.862661] x64_sys_call+0x1058/0x2660<br /> [86.862675] do_syscall_64+0x91/0xe90<br /> [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [86.862703]<br /> -&gt; #2 (&amp;root-&gt;kernfs_rwsem){++++}-{3:3}:<br /> [86.862725] down_write+0x3e/0xf0<br /> [86.862738] kernfs_add_one+0x30/0x3c0<br /> [86.862751] kernfs_create_dir_ns+0x53/0xb0<br /> [86.862765] internal_create_group+0x134/0x4c0<br /> [86.862779] sysfs_create_group+0x13/0x20<br /> [86.862792] topology_add_dev+0x1d/0x30<br /> [86.862806] cpuhp_invoke_callback+0x4b5/0x850<br /> [86.862822] cpuhp_issue_call+0xbf/0x1f0<br /> [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320<br /> [86.862852] __cpuhp_setup_state+0xb0/0x220<br /> [86.862866] topology_sysfs_init+0x30/0x50<br /> [86.862879] do_one_initcall+0x60/0x3f0<br /> [86.862893] kernel_init_freeable+0x3cd/0x680<br /> [86.862908] kernel_init+0x1b/0x200<br /> [86.862921] ret_from_fork+0x47/0x70<br /> [86.862934] ret_from_fork_asm+0x1a/0x30<br /> [86.862947]<br /> -&gt; #1 (cpuhp_state_mutex){+.+.}-{3:3}:<br /> [86.862969] __mutex_lock+0xaa/0xed0<br /> [86.862982] mutex_lock_nested+0x1b/0x30<br /> [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320<br /> [86.863012] __cpuhp_setup_state+0xb0/0x220<br /> [86.863026] page_alloc_init_cpuhp+0x2d/0x60<br /> [86.863041] mm_core_init+0x22/0x2d0<br /> [86.863054] start_kernel+0x576/0xbd0<br /> [86.863068] x86_64_start_reservations+0x18/0x30<br /> [86.863084] x86_64_start_kernel+0xbf/0x110<br /> [86.863098] common_startup_64+0x13e/0x141<br /> [86.863114]<br /> -&gt; #0 (cpu_hotplug_lock){++++}-{0:0}:<br /> [86.863135] __lock_acquire+0x16<br /> ---truncated---