Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: publish GC-visible tuple last<br /> <br /> nf_flow_table_iterate() only treats original-direction tuple nodes as<br /> owning entries. Publishing the original node first lets GC observe and<br /> free a flow while flow_offload_add() is still inserting the reply node.<br /> Publish the reply node first and the original node last so GC never<br /> sees a partially installed flow.<br /> <br /> KASAN can trigger slab-use-after-free read and write reports in the<br /> flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del,<br /> flow_offload_lookup, etc.).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: revalidate ihl to prevent out-of-bounds access<br /> <br /> While the outer IP header is already pulled into the skb head,<br /> we must be careful and revalidate the embedded headers after<br /> reading them from the skb frags to prevent out-of-bounds<br /> access.<br /> <br /> One such place reported by Sashiko is ip_vs_nat_icmp() where<br /> local process can change the ihl field and after<br /> skb_ensure_writable() we can see larger value which is a<br /> problem for the ip_send_check(cih) calls.<br /> <br /> Add check to drop the packet if the ihl field is changed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: fix refcount race between list:set GC and swap<br /> <br /> __ip_set_put_byindex() resolved the index to a set pointer under RCU,<br /> then took ip_set_ref_lock in __ip_set_put() to decrement set-&gt;ref.<br /> ip_set_swap() holds that same lock while swapping both the ip_set_list<br /> slots and the two sets&amp;#39; ref counters, so it can interleave between the<br /> dereference and the lock acquisition, leaving the caller to decrement a<br /> set whose reference already moved to the other index and hit<br /> BUG_ON(set-&gt;ref == 0). list_set_gc() reaches this from timer softirq,<br /> which the nfnl mutex does not serialize against swap: an expiring<br /> list:set member calls list_set_del() -&gt; ip_set_put_byindex() while<br /> IPSET_CMD_SWAP runs on the referenced sets.<br /> <br /> Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap()<br /> already does, keeping the refcount tied to the index rather than to a<br /> stale set pointer.<br /> <br /> kernel BUG at net/netfilter/ipset/ip_set_core.c:685!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870)<br /> Call Trace:<br /> <br /> list_set_del (net/netfilter/ipset/ip_set_list_set.c:159)<br /> set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181)<br /> list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578)<br /> call_timer_fn (kernel/time/timer.c:1748)<br /> __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374)<br /> run_timer_softirq (kernel/time/timer.c:2405)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: fix tunnel and session refcount leak on seq_file release<br /> <br /> In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state<br /> (pd-&gt;tunnel and pd-&gt;session) is kept in seq_file private data to allow<br /> iteration across multiple read() system calls.<br /> <br /> However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels<br /> before reading to end-of-file (EOF), any tunnel or session reference stored in<br /> pd-&gt;tunnel / pd-&gt;session is left un-dropped when seq_file private data is freed.<br /> <br /> Fix this by dropping any remaining pd-&gt;tunnel and pd-&gt;session references in<br /> pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: sdw-mbq: don&amp;#39;t call an unset readable_reg callback<br /> <br /> regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit<br /> by calling ctx-&gt;readable_reg(), which is a straight copy of<br /> config-&gt;readable_reg. That callback is optional: regmap_readable() treats<br /> a NULL -&gt;readable_reg as "every register is readable", and drivers rely on<br /> that. es9356 and tac5xx2-sdw both build an MBQ regmap without one.<br /> <br /> Since commit ca1b11b36d82 ("regmap: sdw-mbq: Allow defers on undeferrable<br /> controls") the poll runs on every -ENODATA, not only for Controls the<br /> driver marked deferrable, so any of those devices answering<br /> COMMAND_IGNORED takes the kernel through a NULL function pointer.<br /> <br /> Treat a missing callback the way the rest of regmap does and poll.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: fix TOCTOU NULL deref on a-&gt;goto_chain<br /> <br /> tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking<br /> rcu_access_pointer(a-&gt;goto_chain) and then calling<br /> tcf_action_goto_chain_exec(), which does a second, independent<br /> rcu_dereference_bh(a-&gt;goto_chain) read and immediately dereferences<br /> chain-&gt;filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact<br /> replace path) can clear a-&gt;goto_chain between the two reads, so the second<br /> read returns NULL and tcf_action_goto_chain_exec() dereferences NULL.<br /> <br /> Fix the race by doing a single rcu_dereference_bh() read of a-&gt;goto_chain<br /> in tcf_action_exec(), checking it once for NULL, and passing the resulting<br /> chain pointer into tcf_action_goto_chain_exec(). This turns the split<br /> check/use into a single check/use on one value.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_bpf: reject dev-bound programs bound to a different device<br /> <br /> cls_bpf_prog_from_efd() obtained a SCHED_CLS program via<br /> bpf_prog_get_type_dev() but never verified that a device-bound (offloaded)<br /> program&amp;#39;s bound netdev matches the TC netdev the classifier is being<br /> attached to. This let a program loaded with prog_ifindex for device A be<br /> attached via cls_bpf + skip_sw to device B; deleting device A then<br /> destroyed the program&amp;#39;s offload state while it was still attached to<br /> device B, triggering a netdevsim WARN (panic with panic_on_warn=1).<br /> <br /> Mirror the XDP attach path (net/core/dev.c) and reject the attach with<br /> -EINVAL when a dev-bound program&amp;#39;s bound device does not match the<br /> target device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG<br /> <br /> On the packet reception path, the ID of the MAC Port on which the packet<br /> was received, is embedded in the RX DMA Descriptor&amp;#39;s metadata. The ID is<br /> extracted using the helper function cppi5_desc_get_tags_ids() which fills<br /> in the 16-bit Source Tag into the &amp;#39;port_id&amp;#39; variable. However, it is only<br /> the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID,<br /> while the upper 8-bits are Hardware-Reserved and carry an arbitrary value.<br /> With the existing logic, sporadic kernel crash is observed due to the<br /> subsequent driver code accessing out-of-bound memory because of an invalid<br /> port_id.<br /> <br /> Hence, fix the port_id extraction logic to use only the lower 8-bits of the<br /> Source Tag as the MAC Port ID.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_u32: skip hash tables in u32_bind_class()<br /> <br /> u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode<br /> through the walker callback. u32_bind_class() unconditionally casts the<br /> passed fh to tc_u_knode and accesses &amp;n-&gt;res, so when fh is actually a<br /> tc_u_hnode, which has no tcf_result member, this results in a<br /> slab-out-of-bounds read of res-&gt;classid in tc_cls_bind_class().<br /> <br /> The issue can be reproduced with the following commands:<br /> <br /> tc qdisc add dev lo root handle 1: hfsc<br /> tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit<br /> tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1<br /> tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit<br /> <br /> Fix this by skipping hash tables via the TC_U32_KEY(handle) check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling<br /> <br /> In non-MSI-X mode (such as legacy INTx or single MSI), wx-&gt;msix_entry is<br /> not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences<br /> wx-&gt;msix_entry-&gt;entry, leading to a NULL pointer dereference crash.<br /> <br /> This issue was introduced by fixing the IRQ vector when the number of<br /> VFs is 7. Fix the issue by explicitly checking `pdev-&gt;msix_enabled` to<br /> determine the correct vector index.<br /> <br /> Additionally, as a side fix, set the interrupt mask to BIT(0) for the<br /> non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts<br /> share vector 0, and the WX_PX_MISC_IVAR register is only valid in the<br /> MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause<br /> when MSI-X is disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix queue index used to wake the peer txq in veth_poll<br /> <br /> veth_poll() derives the index of the peer TX queue to wake from<br /> rq-&gt;xdp_rxq.queue_index. That field is only initialized by<br /> xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an<br /> XDP program is attached. On the plain GRO/NAPI path<br /> (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so<br /> queue_index stays 0 for every queue, as priv-&gt;rq is zero-allocated.<br /> <br /> So in a multi-queue setup with GRO enabled and no XDP program attached,<br /> every NAPI instance looks at the peer&amp;#39;s TX queue 0. If veth_xmit() stops<br /> peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing<br /> ever wakes it again: the poller draining queue 1 wakes queue 0 instead.<br /> veth implements no ndo_tx_timeout, so the netdev watchdog does not kick<br /> in either, and the queue stays stopped indefinitely.<br /> <br /> Derive the index from the position of the rq within priv-&gt;rq instead,<br /> which is correct regardless of whether XDP was ever enabled.<br /> <br /> Scripts to reproduce the stall are available at<br /> https://github.com/netoptimizer/veth-backpressure-performance-testing

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: ohci: fix NULL pointer dereference in ar_context_release<br /> <br /> During the error handling path of the driver&amp;#39;s probe function, a NULL<br /> pointer dereference can occur in ar_context_release().<br /> <br /> When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping<br /> fails), the devres cleanup mechanism invokes release_ohci(). This function<br /> unconditionally calls ar_context_release() to clean up the asynchronous<br /> receive contexts. However, if ar_context_init() was not yet called,<br /> ctx-&gt;ohci remains NULL (as the fw_ohci structure is zero-initialized by<br /> devres_alloc()).<br /> <br /> ar_context_release() immediately dereferences ctx-&gt;ohci to get the dev<br /> pointer before checking if the context was actually initialized, leading to<br /> a crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543<br /> Call Trace:<br /> release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567<br /> release_nodes drivers/base/devres.c:546 [inline]<br /> devres_release_all+0x1a8/0x260 drivers/base/devres.c:576<br /> device_unbind_cleanup drivers/base/dd.c:597 [inline]<br /> really_probe+0x451/0xae0 drivers/base/dd.c:772<br /> <br /> To fix this, move the assignment of the dev pointer after the !ctx-&gt;buffer<br /> check. If ctx-&gt;buffer is NULL, it indicates that the context was never<br /> successfully initialized and there is nothing to release, safely avoiding<br /> the dereference of the uninitialized ctx-&gt;ohci pointer.