Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid double-rtnl_lock ELP metric worker<br /> <br /> batadv_v_elp_get_throughput() might be called when the RTNL lock is already<br /> held. This could be problematic when the work queue item is cancelled via<br /> cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case,<br /> an rtnl_lock() would cause a deadlock.<br /> <br /> To avoid this, rtnl_trylock() was used in this function to skip the<br /> retrieval of the ethtool information in case the RTNL lock was already<br /> held.<br /> <br /> But for cfg80211 interfaces, batadv_get_real_netdev() was called - which<br /> also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must<br /> also be used instead and the lockless version __batadv_get_real_netdev()<br /> has to be called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp-md5: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant<br /> time. Use the appropriate helper function for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp-ao: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant<br /> time. Use the appropriate helper function for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix rcu_tasks stall in threaded busypoll<br /> <br /> I was debugging a NIC driver when I noticed that when I enable<br /> threaded busypoll, bpftrace hangs when starting up. dmesg showed:<br /> <br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 10658 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 40793 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 131273 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 402058 jiffies old.<br /> INFO: rcu_tasks detected stalls on tasks:<br /> 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64<br /> task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000<br /> Call Trace:<br /> <br /> ? napi_threaded_poll_loop+0x27c/0x2c0<br /> ? __pfx_napi_threaded_poll+0x10/0x10<br /> ? napi_threaded_poll+0x26/0x80<br /> ? kthread+0xfa/0x240<br /> ? __pfx_kthread+0x10/0x10<br /> ? ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ? ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> The cause is that in threaded busypoll, the main loop is in<br /> napi_threaded_poll rather than napi_threaded_poll_loop, where the<br /> latter rarely iterates more than once within its loop. For<br /> rcu_softirq_qs_periodic inside napi_threaded_poll_loop to report its<br /> qs state, the last_qs must be 100ms behind, and this can&amp;#39;t happen<br /> because napi_threaded_poll_loop rarely iterates in threaded busypoll,<br /> and each time napi_threaded_poll_loop is called last_qs is reset to<br /> latest jiffies.<br /> <br /> This patch changes so that in threaded busypoll, last_qs is saved<br /> in the outer napi_threaded_poll, and whether busy_poll_last_qs<br /> is NULL indicates whether napi_threaded_poll_loop is called for<br /> busypoll. This way last_qs would not reset to latest jiffies on<br /> each invocation of napi_threaded_poll_loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie<br /> <br /> The current code checks &amp;#39;i + 5

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read<br /> <br /> The q54sj108a2_debugfs_read function suffers from a stack buffer overflow<br /> due to incorrect arguments passed to bin2hex(). The function currently<br /> passes &amp;#39;data&amp;#39; as the destination and &amp;#39;data_char&amp;#39; as the source.<br /> <br /> Because bin2hex() converts each input byte into two hex characters, a<br /> 32-byte block read results in 64 bytes of output. Since &amp;#39;data&amp;#39; is only<br /> 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end<br /> of the buffer onto the stack.<br /> <br /> Additionally, the arguments were swapped: it was reading from the<br /> zero-initialized &amp;#39;data_char&amp;#39; and writing to &amp;#39;data&amp;#39;, resulting in<br /> all-zero output regardless of the actual I2C read.<br /> <br /> Fix this by:<br /> 1. Expanding &amp;#39;data_char&amp;#39; to 66 bytes to safely hold the hex output.<br /> 2. Correcting the bin2hex() argument order and using the actual read count.<br /> 3. Using a pointer to select the correct output buffer for the final<br /> simple_read_from_buffer call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in smb_lazy_parent_lease_break_close()<br /> <br /> opinfo pointer obtained via rcu_dereference(fp-&gt;f_opinfo) is being<br /> accessed after rcu_read_unlock() has been called. This creates a<br /> race condition where the memory could be freed by a concurrent<br /> writer between the unlock and the subsequent pointer dereferences<br /> (opinfo-&gt;is_lease, etc.), leading to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Don&amp;#39;t log keys in SMB3 signing and encryption key generation<br /> <br /> When KSMBD_DEBUG_AUTH logging is enabled, generate_smb3signingkey() and<br /> generate_smb3encryptionkey() log the session, signing, encryption, and<br /> decryption key bytes. Remove the logs to avoid exposing credentials.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free by using call_rcu() for oplock_info<br /> <br /> ksmbd currently frees oplock_info immediately using kfree(), even<br /> though it is accessed under RCU read-side critical sections in places<br /> like opinfo_get() and proc_show_files().<br /> <br /> Since there is no RCU grace period delay between nullifying the pointer<br /> and freeing the memory, a reader can still access oplock_info<br /> structure after it has been freed. This can leads to a use-after-free<br /> especially in opinfo_get() where atomic_inc_not_zero() is called on<br /> already freed memory.<br /> <br /> Fix this by switching to deferred freeing using call_rcu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: fix device leak on probe failure<br /> <br /> Driver core holds a reference to the USB interface and its parent USB<br /> device while the interface is bound to a driver and there is no need to<br /> take additional references unless the structures are needed after<br /> disconnect.<br /> <br /> This driver takes a reference to the USB device during probe but does<br /> not to release it on probe failures.<br /> <br /> Drop the redundant device reference to fix the leak, reduce cargo<br /> culting, make it easier to spot drivers where an extra reference is<br /> needed, and reduce the risk of further memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nexthop: fix percpu use-after-free in remove_nh_grp_entry<br /> <br /> When removing a nexthop from a group, remove_nh_grp_entry() publishes<br /> the new group via rcu_assign_pointer() then immediately frees the<br /> removed entry&amp;#39;s percpu stats with free_percpu(). However, the<br /> synchronize_net() grace period in the caller remove_nexthop_from_groups()<br /> runs after the free. RCU readers that entered before the publish still<br /> see the old group and can dereference the freed stats via<br /> nh_grp_entry_stats_inc() -&gt; get_cpu_ptr(nhge-&gt;stats), causing a<br /> use-after-free on percpu memory.<br /> <br /> Fix by deferring the free_percpu() until after synchronize_net() in the<br /> caller. Removed entries are chained via nh_list onto a local deferred<br /> free list. After the grace period completes and all RCU readers have<br /> finished, the percpu stats are safely freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ncsi: fix skb leak in error paths<br /> <br /> Early return paths in NCSI RX and AEN handlers fail to release<br /> the received skb, resulting in a memory leak.<br /> <br /> Specifically, ncsi_aen_handler() returns on invalid AEN packets<br /> without consuming the skb. Similarly, ncsi_rcv_rsp() exits early<br /> when failing to resolve the NCSI device, response handler, or<br /> request, leaving the skb unfreed.