Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: cfm: Fix race condition in peer_mep deletion<br /> <br /> When a peer MEP is being deleted, cancel_delayed_work_sync() is called<br /> on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in<br /> softirq context under rcu_read_lock (without RTNL) and can re-schedule<br /> ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()<br /> returning and kfree_rcu() being called.<br /> <br /> The following is a simple race scenario:<br /> <br /> cpu0 cpu1<br /> <br /> mep_delete_implementation()<br /> cancel_delayed_work_sync(ccm_rx_dwork);<br /> br_cfm_frame_rx()<br /> // peer_mep still in hlist<br /> if (peer_mep-&gt;ccm_defect)<br /> ccm_rx_timer_start()<br /> queue_delayed_work(ccm_rx_dwork)<br /> hlist_del_rcu(&amp;peer_mep-&gt;head);<br /> kfree_rcu(peer_mep, rcu);<br /> ccm_rx_work_expired()<br /> // on freed peer_mep<br /> <br /> To prevent this, cancel_delayed_work_sync() is replaced with<br /> disable_delayed_work_sync() in both peer MEP deletion paths, so<br /> that subsequent queue_delayed_work() calls from br_cfm_frame_rx()<br /> are silently rejected.<br /> <br /> The cc_peer_disable() helper retains cancel_delayed_work_sync()<br /> because it is also used for the CC enable/disable toggle path where<br /> the work must remain re-schedulable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Give up GC if MSG_PEEK intervened.<br /> <br /> Igor Ushakov reported that GC purged the receive queue of<br /> an alive socket due to a race with MSG_PEEK with a nice repro.<br /> <br /> This is the exact same issue previously fixed by commit<br /> cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").<br /> <br /> After GC was replaced with the current algorithm, the cited<br /> commit removed the locking dance in unix_peek_fds() and<br /> reintroduced the same issue.<br /> <br /> The problem is that MSG_PEEK bumps a file refcount without<br /> interacting with GC.<br /> <br /> Consider an SCC containing sk-A and sk-B, where sk-A is<br /> close()d but can be recv()ed via sk-B.<br /> <br /> The bad thing happens if sk-A is recv()ed with MSG_PEEK from<br /> sk-B and sk-B is close()d while GC is checking unix_vertex_dead()<br /> for sk-A and sk-B.<br /> <br /> GC thread User thread<br /> --------- -----------<br /> unix_vertex_dead(sk-A)<br /> -&gt; true sk-A&amp;#39;s file refcount : 1 -&gt; 2<br /> <br /> close(sk-B)<br /> -&gt; sk-B&amp;#39;s file refcount : 2 -&gt; 1<br /> unix_vertex_dead(sk-B)<br /> -&gt; true<br /> <br /> Initially, sk-A&amp;#39;s file refcount is 1 by the inflight fd in sk-B<br /> recvq. GC thinks sk-A is dead because the file refcount is the<br /> same as the number of its inflight fds.<br /> <br /> However, sk-A&amp;#39;s file refcount is bumped silently by MSG_PEEK,<br /> which invalidates the previous evaluation.<br /> <br /> At this moment, sk-B&amp;#39;s file refcount is 2; one by the open fd,<br /> and one by the inflight fd in sk-A. The subsequent close()<br /> releases one refcount by the former.<br /> <br /> Finally, GC incorrectly concludes that both sk-A and sk-B are dead.<br /> <br /> One option is to restore the locking dance in unix_peek_fds(),<br /> but we can resolve this more elegantly thanks to the new algorithm.<br /> <br /> The point is that the issue does not occur without the subsequent<br /> close() and we actually do not need to synchronise MSG_PEEK with<br /> the dead SCC detection.<br /> <br /> When the issue occurs, close() and GC touch the same file refcount.<br /> If GC sees the refcount being decremented by close(), it can just<br /> give up garbage-collecting the SCC.<br /> <br /> Therefore, we only need to signal the race during MSG_PEEK with<br /> a proper memory barrier to make it visible to the GC.<br /> <br /> Let&amp;#39;s use seqcount_t to notify GC when MSG_PEEK occurs and let<br /> it defer the SCC to the next run.<br /> <br /> This way no locking is needed on the MSG_PEEK side, and we can<br /> avoid imposing a penalty on every MSG_PEEK unnecessarily.<br /> <br /> Note that we can retry within unix_scc_dead() if MSG_PEEK is<br /> detected, but we do not do so to avoid hung task splat from<br /> abusive MSG_PEEK calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ<br /> <br /> Currently the code attempts to accept requests regardless of the<br /> command identifier which may cause multiple requests to be marked<br /> as pending (FLAG_DEFER_SETUP) which can cause more than<br /> L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer<br /> causing an overflow.<br /> <br /> The spec is quite clear that the same identifier shall not be used on<br /> subsequent requests:<br /> <br /> &amp;#39;Within each signaling channel a different Identifier shall be used<br /> for each successive request or indication.&amp;#39;<br /> https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d<br /> <br /> So this attempts to check if there are any channels pending with the<br /> same identifier and rejects if any are found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe()<br /> <br /> devm_add_action_or_reset() already invokes the action on failure,<br /> so the explicit put causes a double-put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: check metadata block offset is within range<br /> <br /> Syzkaller reports a "general protection fault in squashfs_copy_data"<br /> <br /> This is ultimately caused by a corrupted index look-up table, which<br /> produces a negative metadata block offset.<br /> <br /> This is subsequently passed to squashfs_copy_data (via<br /> squashfs_read_metadata) where the negative offset causes an out of bounds<br /> access.<br /> <br /> The fix is to check that the offset is within range in<br /> squashfs_read_metadata. This will trap this and other cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix memory leak in ice_set_ringparam()<br /> <br /> In ice_set_ringparam, tx_rings and xdp_rings are allocated before<br /> rx_rings. If the allocation of rx_rings fails, the code jumps to<br /> the done label leaking both tx_rings and xdp_rings. Furthermore, if<br /> the setup of an individual Rx ring fails during the loop, the code jumps<br /> to the free_tx label which releases tx_rings but leaks xdp_rings.<br /> <br /> Fix this by introducing a free_xdp label and updating the error paths to<br /> ensure both xdp_rings and tx_rings are properly freed if rx_rings<br /> allocation or setup fails.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow<br /> <br /> The dma_map_sg tracepoint can trigger a perf buffer overflow when<br /> tracing large scatter-gather lists. With devices like virtio-gpu<br /> creating large DRM buffers, nents can exceed 1000 entries, resulting<br /> in:<br /> <br /> phys_addrs: 1000 * 8 bytes = 8,000 bytes<br /> dma_addrs: 1000 * 8 bytes = 8,000 bytes<br /> lengths: 1000 * 4 bytes = 4,000 bytes<br /> Total: ~20,000 bytes<br /> <br /> This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:<br /> <br /> WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405<br /> perf buffer not large enough, wanted 24620, have 8192<br /> <br /> Cap all three dynamic arrays at 128 entries using min() in the array<br /> size calculation. This ensures arrays are only as large as needed<br /> (up to the cap), avoiding unnecessary memory allocation for small<br /> operations while preventing overflow for large ones.<br /> <br /> The tracepoint now records the full nents/ents counts and a truncated<br /> flag so users can see when data has been capped.<br /> <br /> Changes in v2:<br /> - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing<br /> instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from<br /> Steven Rostedt)<br /> - This allocates only what&amp;#39;s needed up to the cap, avoiding waste<br /> for small operations<br /> <br /> Reviwed-by: Sean Anderson

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_CT: drop pending enqueued packets on template removal<br /> <br /> Templates refer to objects that can go away while packets are sitting in<br /> nfqueue refer to:<br /> <br /> - helper, this can be an issue on module removal.<br /> - timeout policy, nfnetlink_cttimeout might remove it.<br /> <br /> The use of templates with zone and event cache filter are safe, since<br /> this just copies values.<br /> <br /> Flush these enqueued packets in case the template rule gets removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flowtable after rcu grace period on error<br /> <br /> Call synchronize_rcu() after unregistering the hooks from error path,<br /> since a hook that already refers to this flowtable can be already<br /> registered, exposing this flowtable to packet path and nfnetlink_hook<br /> control plane.<br /> <br /> This error path is rare, it should only happen by reaching the maximum<br /> number hooks or by failing to set up to hardware offload, just call<br /> synchronize_rcu().<br /> <br /> There is a check for already used device hooks by different flowtable<br /> that could result in EEXIST at this late stage. The hook parser can be<br /> updated to perform this check earlier to this error path really becomes<br /> rarely exercised.<br /> <br /> Uncovered by KASAN reported as use-after-free from nfnetlink_hook path<br /> when dumping hooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix WARN_ON in tracing_buffers_mmap_close<br /> <br /> When a process forks, the child process copies the parent&amp;#39;s VMAs but the<br /> user_mapped reference count is not incremented. As a result, when both the<br /> parent and child processes exit, tracing_buffers_mmap_close() is called<br /> twice. On the second call, user_mapped is already 0, causing the function to<br /> return -ENODEV and triggering a WARN_ON.<br /> <br /> Normally, this isn&amp;#39;t an issue as the memory is mapped with VM_DONTCOPY set.<br /> But this is only a hint, and the application can call<br /> madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the<br /> application does that, it can trigger this issue on fork.<br /> <br /> Fix it by incrementing the user_mapped reference count without re-mapping<br /> the pages in the VMA&amp;#39;s open callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled<br /> <br /> When booting with the &amp;#39;ipv6.disable=1&amp;#39; parameter, the nd_tbl is never<br /> initialized because inet6_init() exits before ndisc_init() is called<br /> which initializes it. Then, if neigh_suppress is enabled and an ICMPv6<br /> Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will<br /> dereference ipv6_stub-&gt;nd_tbl which is NULL, passing it to<br /> neigh_lookup(). This causes a kernel NULL pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000268<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [...]<br /> RIP: 0010:neigh_lookup+0x16/0xe0<br /> [...]<br /> Call Trace:<br /> <br /> ? neigh_lookup+0x16/0xe0<br /> br_do_suppress_nd+0x160/0x290 [bridge]<br /> br_handle_frame_finish+0x500/0x620 [bridge]<br /> br_handle_frame+0x353/0x440 [bridge]<br /> __netif_receive_skb_core.constprop.0+0x298/0x1110<br /> __netif_receive_skb_one_core+0x3d/0xa0<br /> process_backlog+0xa0/0x140<br /> __napi_poll+0x2c/0x170<br /> net_rx_action+0x2c4/0x3a0<br /> handle_softirqs+0xd0/0x270<br /> do_softirq+0x3f/0x60<br /> <br /> Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in<br /> the callers. This is in essence disabling NS/NA suppression when IPv6 is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them<br /> <br /> In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at<br /> raw event handle"), we handle the fact that raw event callbacks<br /> can happen even for a HID device that has not been "claimed" causing a<br /> crash if a broken device were attempted to be connected to the system.<br /> <br /> Fix up the remaining in-tree HID drivers that forgot to add this same<br /> check to resolve the same issue.