Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: validate metadata when processing requests<br /> <br /> The zero-copy path validates TX metadata while obtaining the descriptor<br /> context, then reads it again later when preparing the hardware request.<br /> User space can change the metadata between those operations and bypass the<br /> original validation.<br /> <br /> Validate the metadata in xsk_tx_metadata_request() and use the resulting<br /> flags snapshot for every feature check. Read request fields once so all<br /> zero-copy drivers process only values observed after successful<br /> validation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: validate launch-time metadata size<br /> <br /> Launch-time metadata extends beyond the first 16 bytes of struct<br /> xsk_tx_metadata. Reject the request when the registered metadata area does<br /> not contain the complete field.<br /> <br /> Snapshot the validated flags for the generic transmit path and use that<br /> snapshot for request and completion processing, avoiding inconsistent<br /> decisions if user space changes the flags concurrently.<br /> <br /> Note that only xsk_skb_metadata is properly using the flags,<br /> __xsk_buff_get_metadata ignores them. Next commits address that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: clear metadata pointer when no timestamp is requested<br /> <br /> User space can change metadata flags after request processing. Rereading<br /> them during completion can therefore make the kernel write a timestamp<br /> that was not requested when the packet was submitted.<br /> <br /> Clear the metadata pointer during request processing unless timestamp<br /> completion is requested. Completion handling can then use the pointer<br /> itself instead of rereading the flags.<br /> <br /> On the mlx5 multi-packet WQE path metadata is evaluated per batch:<br /> xsk_tx_metadata_request() runs only for the descriptor that starts a<br /> session, just like the checksum offload that is applied once through the<br /> shared WQE. Only that descriptor&amp;#39;s pointer is reset, so completion<br /> handling can record a timestamp for the other descriptors of the session<br /> regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays<br /> inside the metadata area; the single-WQE, other zero-copy, and generic<br /> paths reset the pointer per descriptor and are unaffected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: require at least 16 bytes of TX metadata<br /> <br /> AF_XDP accepts a TX metadata length as small as eight bytes, but every<br /> supported request needs the flags plus at least one eight-byte request<br /> field. Such short metadata also lets the kernel read beyond the registered<br /> area.<br /> <br /> Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve<br /> compatibility with applications that do not use launch-time metadata.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus) Fix type confusion in notification logic<br /> <br /> Sashiko reports:<br /> <br /> At the start of the loop in pmbus_notify(), the code unconditionally casts<br /> every attribute to a struct sensor_device_attribute:<br /> <br /> drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() {<br /> for (i = 0; i num_attributes; i++) {<br /> struct device_attribute *da = to_dev_attr(data-&gt;group.attrs[i]);<br /> struct sensor_device_attribute *attr = to_sensor_dev_attr(da);<br /> int index = attr-&gt;index;<br /> ...<br /> }<br /> <br /> However, data-&gt;group.attrs can contain other types like struct<br /> pmbus_samples_reg or struct pmbus_sensor, which only embed a base<br /> struct device_attribute.<br /> <br /> If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting<br /> it to struct sensor_device_attribute and reading the index field appears<br /> to access memory past the end of the allocation, which might trigger a<br /> slab-out-of-bounds read.<br /> <br /> Additionally, if da is a struct pmbus_sensor, casting it causes the index<br /> field to overlap with the page, phase, and reg fields. Could this produce<br /> a garbage mask on little-endian systems that spuriously matches the target<br /> reg, page, and flags during an alert?<br /> <br /> Fix the problem by using struct sensor_device_attr in struct pmbus_sensor<br /> and struct pmbus_label. Since those attributes never trigger a<br /> notification, set the value of attr-&gt;index to -1 for them. Use this value<br /> to distinguish from boolean attributes which _can_ trigger a notification<br /> and use the index field to encode mask, page, and register values.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: Fix buffer length in create_direct_keys()<br /> <br /> We have seen in our CI the following KASAN message:<br /> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]<br /> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764<br /> [...]<br /> [] cmd_exec+0x550/0xca0 [mlx5_core]<br /> [] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]<br /> [] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]<br /> [] create_direct_keys+0x954/0xef0 [mlx5_vdpa]<br /> [...]<br /> The buggy address is located 4128 bytes inside of<br /> allocated 4384-byte region [0000000176794000, 0000000176795120)<br /> <br /> So in essence we read 16 bytes beyond 4384-byte allocation.<br /> create_direct_keys calculates the pointer and length for in and out<br /> buffers.<br /> The size calculation for in includes the entire structure<br /> size (out + in + mtt[]) but the pointer passed to cmd_exec points only<br /> to the &amp;#39;in&amp;#39; field, skipping the &amp;#39;out&amp;#39; field.<br /> <br /> This causes mlx5_copy_to_msg() to read beyond the allocated buffer<br /> by sizeof(out) bytes when copying command data.<br /> <br /> Properly calculate the input size to match the pointer and allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref()<br /> <br /> Incoming skbs passing through netfilter flowtable offload hooks (or XFRM<br /> offload path) might already carry a ref-counted dst_entry assigned during<br /> earlier RX or routing steps.<br /> <br /> Calling skb_dst_set_noref() when skb already holds a ref-counted dst<br /> overwrites skb-&gt;_skb_refdst, leaking the previous dst_entry reference<br /> count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in<br /> skb_dst_check_unset():<br /> <br /> WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170<br /> WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234<br /> WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864<br /> <br /> Drop any existing dst_entry reference with skb_dst_drop(skb) before<br /> setting the non-referenced flowtable destination.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix TFO max_qlen accounting across reuseport migration<br /> <br /> A listener&amp;#39;s TCP_FASTOPEN max_qlen stops being accurate and lets through<br /> far more pending Fast Open requests than it was configured for.<br /> <br /> This only shows up with SO_REUSEPORT listener migration, where closing a<br /> listener hands its still-pending TFO children over to a surviving one.<br /> <br /> fastopenq.qlen is charged in tcp_fastopen_create_child() when the child<br /> is created and uncharged in reqsk_fastopen_remove() when the handshake<br /> completes. The uncharge follows rsk_listener of the request the child<br /> points at, and inet_reqsk_clone() has repointed the child at a new<br /> request owned by the new listener, so the ++ and the -- land on two<br /> different sockets. The new listener&amp;#39;s qlen drifts negative and its<br /> limit no longer binds.<br /> <br /> Charge the new listener during migration, like reqsk_queue_migrated()<br /> already does for queue-&gt;young and queue-&gt;qlen.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Disable EOP for TPA on all chips to prevent data corruption<br /> <br /> EOP (End of frame padding) on the AGG ring may cause overlapping of<br /> zero padding at the end of one segment with the next segment&amp;#39;s data.<br /> If Relaxed Ordering (RO) is enabled, the zero padding may overwrite<br /> valid data in the next segment and corrupt the data. Older chips<br /> (P5 and older) do not automatically disable RO when EOP is enabled.<br /> On some ARM systems, data corruption was reported on 57508 (P5)<br /> chips with RO enabled.<br /> <br /> Always disable EOP on all chips on the AGG rings when TPA is enabled<br /> to fix the data corruption.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: fix BQL reset on SQ re-activation<br /> <br /> mlx5e_queue_start() deactivates and re-activates all channels but closes<br /> only the queue being restarted. mlx5e_activate_txqsq() then<br /> unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters<br /> of channels that kept their in-flight TX WQEs. The next completion then<br /> over-charges and trips the BUG_ON() in dql_completed():<br /> <br /> kernel BUG at lib/dynamic_queue_limits.c:99!<br /> RIP: 0010:dql_completed+0x23d/0x280<br /> Call Trace:<br /> <br /> mlx5e_poll_tx_cq+0x668/0xa60<br /> mlx5e_napi_poll+0x5b/0x7b0<br /> net_rx_action+0x15a/0x580<br /> <br /> Reset BQL only when the SQ has no bytes in flight (sq-&gt;cc == sq-&gt;pc).<br /> <br /> In the case that reset is skipped, the outstanding WQEs will eventually<br /> complete and rebalance the dql. The dql-&gt;limit is carried across the<br /> reset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix memory leak in exec_queue_set_hang_replay_state()<br /> <br /> The q-&gt;replay_state is blindly overwritten, which can potentially leak<br /> memory that was previously allocated by vmemdup_user().<br /> Return an error if q-&gt;replay_state is not empty.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers<br /> <br /> Another challenge with unlocked filters.<br /> There is a short window in tc_new_tfilter where a tcf_proto can be found<br /> and briefly referenced by a totally unrelated, unlocked classifier&amp;#39;s request<br /> and cause a race.<br /> <br /> Feng created a poc which created this race with two threads, one creating a<br /> u32 filter and other a flower filter in the same chain/prio:<br /> <br /> 1. Both threads enter tc_new_tfilter, both find the chain empty, both<br /> drop filter_chain_lock<br /> 2. u32 finishes tcf_proto_create("u32") first, calls<br /> tcf_chain_tp_insert_unique() -&gt; inserts u32_tp into the chain<br /> 3. flower finishes tcf_proto_create("flower") later, calls<br /> tcf_chain_tp_insert_unique() -&gt; tcf_chain_tp_find() now sees u32_tp<br /> already there, takes a reference on it, destroys flower&amp;#39;s own tp_new<br /> and returns u32_tp to the caller.<br /> <br /> Flower then hits the kind mismatch check (because it requested for kind<br /> "flower" but tp-&gt;ops-&gt;kind is "u32") and goes through the errout path<br /> which calls tcf_proto_put() on u32_tp. If the u32 thread has already<br /> gone through its own errout (its change() call failed on the PoC&amp;#39;s empty<br /> options) and dropped its create and insert refs, flower&amp;#39;s put is the<br /> last one and drops u32_tp&amp;#39;s refcnt to zero.<br /> <br /> At this point tp-&gt;ops-&gt;destroy() runs in a context that never took<br /> rtnl_lock. When that happens, it might cause a UAF like the following<br /> (illustrated by the PoC):<br /> <br /> [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393)<br /> [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524<br /> <br /> Call Trace:<br /> u32_init (net/sched/cls_u32.c:393)<br /> tc_new_tfilter (net/sched/cls_api.c:2378)<br /> <br /> Allocated by task 526:<br /> u32_init (net/sched/cls_u32.c:378)<br /> tc_new_tfilter (net/sched/cls_api.c:2378)<br /> <br /> Freed by task 522:<br /> kfree<br /> u32_destroy (net/sched/cls_u32.c:662)<br /> tcf_proto_destroy (net/sched/cls_api.c:446)<br /> tcf_proto_put (net/sched/cls_api.c:459)<br /> tc_new_tfilter (net/sched/cls_api.c:2459)<br /> <br /> Fix this by having tcf_proto_destroy() take rtnl_lock around<br /> tp-&gt;ops-&gt;destroy() for locked classifiers whenever rtnl is not held.<br /> <br /> To explain why I used a temp variable "not_lockless" I&amp;#39;d like to point to a<br /> semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here<br /> for future cleanup if deemed necessary):<br /> The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are<br /> redundant sources of truth for whether rtnl_lock is held. Among the nine<br /> classifier destroy(..rtnl_held..) callbacks, only flower consults the<br /> rtnl_held parameter which it propagates to tc_setup_cb_destroy()<br /> and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic,<br /> fw, mall) ignore it entirely;-&gt; those that call tc_setup_cb_destroy()<br /> (u32, bpf, mall) hardcode true always instead of forwarding the parameter.<br /> <br /> A future cleanup should remove the rtnl_held parameter from the destroy callback<br /> signature entirely and have callers rely solely on their knowledge whether<br /> they are running in an unlocked context.