Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix integer overflow in UNMAP bounds check<br /> <br /> sbc_execute_unmap() checks LBA + range does not exceed the device capacity,<br /> but does not guard against LBA + range wrapping around on 64-bit overflow.<br /> <br /> Add an overflow check matching the pattern already used for WRITE_SAME in<br /> the same file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix potential race condition in TLB sync<br /> <br /> During the TLB sync, we need to traverse and modify the page table,<br /> so we should hold the page table lock. Since full SMP support for<br /> threads within the same process is still missing, let&amp;#39;s disable the<br /> split page table lock for simplicity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free on cdev close<br /> <br /> This addresses a use-after-free bug when a raw bundle is disconnected<br /> but its chardev is still opened by an application. When the application<br /> releases the cdev, it causes the following panic when init on free is<br /> enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130<br /> ...<br /> Call Trace:<br /> <br /> cdev_put+0x18/0x30<br /> __fput+0x255/0x2a0<br /> __x64_sys_close+0x3d/0x80<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The cdev is contained in the "gb_raw" structure, which is freed in the<br /> disconnect operation. When the cdev is released at a later time,<br /> cdev_put gets an address that points to freed memory.<br /> <br /> To fix this use-after-free, convert the struct device from a pointer to<br /> being embedded, that makes the lifetime of the cdev and of this device<br /> the same. Then, use cdev_device_add, which guarantees that the device<br /> won&amp;#39;t be released until all references to the cdev have been released.<br /> Finally, delegate the freeing of the structure to the device release<br /> function, instead of freeing immediately in the disconnect callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg<br /> <br /> In nfsd4_add_rdaccess_to_wrdeleg, if fp-&gt;fi_fds[O_RDONLY] is already<br /> set by another thread, __nfs4_file_get_access should not be called<br /> to increment the nfs4_file access count since that was already done<br /> by the thread that added READ access to the file. The extra fi_access<br /> count in nfs4_file can prevent the corresponding nfsd_file from being<br /> freed.<br /> <br /> When stopping nfs-server service, these extra access counts trigger a<br /> BUG in kmem_cache_destroy() that shows nfsd_file object remaining on<br /> __kmem_cache_shutdown.<br /> <br /> This problem can be reproduced by running the Git project&amp;#39;s test<br /> suite over NFS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - copy IV using skcipher ivsize<br /> <br /> AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.<br /> <br /> ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller&amp;#39;s IV<br /> buffer while RFC3686 skciphers expose an 8-byte IV, so the restore<br /> overruns the provided buffer.<br /> <br /> Use crypto_skcipher_ivsize() to copy only the algorithm&amp;#39;s IV length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: unify lcn as u64 for 32-bit platforms<br /> <br /> As sashiko reported [1], `lcn` was typed as `unsigned long` (or<br /> `unsigned int` sometimes), which is only 32 bits wide on 32-bit<br /> platforms, which causes `(lcn

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir<br /> <br /> In tcf_blockcast_redir(), when iterating block ports to redirect<br /> packets to multiple devices, the mac_header_xmit flag is queried<br /> from the wrong device. The loop sends to dev_prev but queries<br /> dev_is_mac_header_xmit(dev) — which is the NEXT device in the<br /> iteration, not the one being sent to.<br /> <br /> This causes tcf_mirred_to_dev() to make incorrect decisions about<br /> whether to push or pull the MAC header. When the block contains<br /> mixed device types (e.g., an ethernet veth and a tunnel device),<br /> intermediate devices get the wrong mac_header_xmit flag, leading to<br /> skb header corruption. In the worst case, skb_push_rcsum with an<br /> incorrect mac_len can exhaust headroom and panic.<br /> <br /> The last device in the loop is handled correctly (line 365-366 uses<br /> dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste<br /> oversight for the intermediate devices.<br /> <br /> Fix by using dev_prev instead of dev for the mac_header_xmit query,<br /> consistent with the device actually being sent to.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF<br /> <br /> macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but<br /> macvlan_fill_info() conditionally includes it when port-&gt;bc_cutoff != 1.<br /> This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb<br /> runs out of space, triggering a WARN_ON in rtnetlink and preventing the<br /> interface from being dumped.<br /> <br /> The bug can be reproduced with:<br /> <br /> ip link add macvlan0 link eth0 type macvlan mode bridge<br /> ip link set macvlan0 type macvlan bc_cutoff 0<br /> ip -d link show macvlan0 # fails with -EMSGSIZE<br /> <br /> The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add<br /> netlink attribute for broadcast cutoff"), which added the nla_put_s32()<br /> call in macvlan_fill_info() but missed adding the corresponding<br /> nla_total_size(4) in macvlan_get_size(). A follow-up commit<br /> 55cef78c244d ("macvlan: add forgotten nla_policy for<br /> IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still<br /> did not fix the size calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: fix IPv6 route referencing IPv4 nexthop<br /> <br /> syzbot reported a panic [1] [2].<br /> <br /> When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag<br /> of all groups containing this nexthop is not updated. This is because<br /> nh_group_v4_update is only called when replacing AF_INET to AF_INET6,<br /> but the reverse direction (AF_INET6 to AF_INET) is missed.<br /> <br /> This allows a stale has_v4=false to bypass fib6_check_nexthop, causing<br /> IPv6 routes to be attached to groups that effectively contain only AF_INET<br /> members. Subsequent route lookups then call nexthop_fib6_nh() which<br /> returns NULL for the AF_INET member, leading to a NULL pointer<br /> dereference.<br /> <br /> Fix by calling nh_group_v4_update whenever the family changes, not just<br /> AF_INET to AF_INET6.<br /> <br /> Reproducer:<br /> # AF_INET6 blackhole<br /> ip -6 nexthop add id 1 blackhole<br /> # group with has_v4=false<br /> ip nexthop add id 100 group 1<br /> # replace with AF_INET (no -6), has_v4 stays false<br /> ip nexthop replace id 1 blackhole<br /> # pass stale has_v4 check<br /> ip -6 route add 2001:db8::/64 nhid 100<br /> # panic<br /> ping -6 2001:db8::1<br /> <br /> [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0<br /> [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: fix use-after-free in advance_sched() on schedule switch<br /> <br /> In advance_sched(), when should_change_schedules() returns true,<br /> switch_schedules() is called to promote the admin schedule to oper.<br /> switch_schedules() queues the old oper schedule for RCU freeing via<br /> call_rcu(), but &amp;#39;next&amp;#39; still points into an entry of the old oper<br /> schedule. The subsequent &amp;#39;next-&gt;end_time = end_time&amp;#39; and<br /> rcu_assign_pointer(q-&gt;current_entry, next) are use-after-free.<br /> <br /> Fix this by selecting &amp;#39;next&amp;#39; from the new oper schedule immediately<br /> after switch_schedules(), and using its pre-calculated end_time.<br /> setup_first_end_time() sets the first entry&amp;#39;s end_time to<br /> base_time + interval when the schedule is installed, so the value<br /> is already correct.<br /> <br /> The deleted &amp;#39;end_time = sched_base_time(admin)&amp;#39; assignment was also<br /> harmful independently: it would overwrite the new first entry&amp;#39;s<br /> pre-calculated end_time with just base_time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in smb2_open during durable reconnect<br /> <br /> In smb2_open, the call to ksmbd_put_durable_fd(fp) drops the reference<br /> to the durable file descriptor early during the durable reconnect<br /> process. If an error occurs subsequently (eg, ksmbd_iov_pin_rsp fails)<br /> or a scavenger accesses the file, it leads to a use-after-free when<br /> accessing fp properties (eg fp-&gt;create_time).<br /> <br /> Move the single put to the end of the function below err_out2 so fp<br /> stays valid until smb2_open returns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix race condition in TX timestamp ring cleanup<br /> <br /> Fix a race condition between ice_free_tx_tstamp_ring() and ice_tx_map()<br /> that can cause a NULL pointer dereference.<br /> <br /> ice_free_tx_tstamp_ring currently clears the ICE_TX_FLAGS_TXTIME flag<br /> after NULLing the tstamp_ring. This could allow a concurrent ice_tx_map<br /> call on another CPU to dereference the tstamp_ring, which could lead to<br /> a NULL pointer dereference.<br /> <br /> CPU A:ice_free_tx_tstamp_ring() | CPU B:ice_tx_map()<br /> --------------------------------|---------------------------------<br /> tx_ring-&gt;tstamp_ring = NULL |<br /> | ice_is_txtime_cfg() -&gt; true<br /> | tstamp_ring = tx_ring-&gt;tstamp_ring<br /> | tstamp_ring-&gt;count // NULL deref!<br /> flags &amp;= ~ICE_TX_FLAGS_TXTIME |<br /> <br /> Fix by:<br /> 1. Reordering ice_free_tx_tstamp_ring() to clear the flag before<br /> NULLing the pointer, with smp_wmb() to ensure proper ordering.<br /> 2. Adding smp_rmb() in ice_tx_map() after the flag check to order the<br /> flag read before the pointer read, using READ_ONCE() for the<br /> pointer, and adding a NULL check as a safety net.<br /> 3. Converting tx_ring-&gt;flags from u8 to DECLARE_BITMAP() and using<br /> atomic bitops (set_bit(), clear_bit(), test_bit()) for all flag<br /> operations throughout the driver:<br /> - ICE_TX_RING_FLAGS_XDP<br /> - ICE_TX_RING_FLAGS_VLAN_L2TAG1<br /> - ICE_TX_RING_FLAGS_VLAN_L2TAG2<br /> - ICE_TX_RING_FLAGS_TXTIME