Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Restrict use of RDS/IB to the initial network namespace<br /> <br /> Prevent using RDS/IB in network namespaces other than the initial one.<br /> The existing RDS/IB code will not work properly in non-initial network<br /> namespaces.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: fix skb memory leak in deferred qdisc drops<br /> <br /> When the network stack cleans up the deferred list via qdisc_run_end(),<br /> it operates on the root qdisc. If the root qdisc do not implement the<br /> TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and<br /> gets stranded on the child&amp;#39;s local to_free list.<br /> <br /> Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It<br /> fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If<br /> the flag is present, the packet is appended directly to the root&amp;#39;s<br /> to_free list. Otherwise, drop it directly as it was done before the<br /> optimization was implemented.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops<br /> <br /> When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,<br /> the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the<br /> destination register in the !fullsock / !locked_tcp_sock path.<br /> <br /> Both macros borrow a temporary register to check is_fullsock /<br /> is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the<br /> ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with<br /> a request_sock), dst_reg should be zeroed but is not, leaving the stale<br /> ctx pointer:<br /> <br /> - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks<br /> as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer,<br /> leading to stack-out-of-bounds access in helpers like<br /> bpf_skc_to_tcp6_sock().<br /> <br /> - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the<br /> verifier believes is a SCALAR_VALUE, leaking a kernel pointer.<br /> <br /> Fix both macros by:<br /> - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the<br /> added instruction.<br /> - Adding BPF_MOV64_IMM(si-&gt;dst_reg, 0) after the temp register<br /> restore in the !fullsock path, placed after the restore because<br /> dst_reg == src_reg means we need src_reg intact to read ctx-&gt;temp.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master<br /> <br /> syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via<br /> xdp_master_redirect(). Full decoded trace:<br /> <br /> https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73<br /> <br /> bond_rr_gen_slave_id() dereferences bond-&gt;rr_tx_counter, a per-CPU<br /> counter that bonding only allocates in bond_open() when the mode is<br /> round-robin. If the bond device was never brought up, rr_tx_counter<br /> stays NULL.<br /> <br /> The XDP redirect path can still reach that code on a bond that was<br /> never opened: bpf_master_redirect_enabled_key is a global static key,<br /> so as soon as any bond device has native XDP attached, the<br /> XDP_TX -&gt; xdp_master_redirect() interception is enabled for every<br /> slave system-wide. The path xdp_master_redirect() -&gt;<br /> bond_xdp_get_xmit_slave() -&gt; bond_xdp_xmit_roundrobin_slave_get() -&gt;<br /> bond_rr_gen_slave_id() then runs against a bond that has no<br /> rr_tx_counter and crashes.<br /> <br /> Fix this in the generic xdp_master_redirect() by refusing to call into<br /> the master&amp;#39;s -&gt;ndo_xdp_get_xmit_slave() when the master device is not<br /> up. IFF_UP is only set after -&gt;ndo_open() has successfully returned,<br /> so this reliably excludes masters whose XDP state has not been fully<br /> initialized. Drop the frame with XDP_ABORTED so the exception is<br /> visible via trace_xdp_exception() rather than silently falling through.<br /> This is not specific to bonding: any current or future master that<br /> defers XDP state allocation to -&gt;ndo_open() is protected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: disable BH before calling udp_tunnel_xmit_skb()<br /> <br /> udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with<br /> BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to<br /> tunnel xmit functions"), on the path:<br /> <br /> udp(6)_tunnel_xmit_skb() -&gt; ip(6)tunnel_xmit()<br /> <br /> dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU.<br /> <br /> Without local_bh_disable(), the context may move between CPUs, which can<br /> break the inc/dec pairing. This may lead to incorrect recursion level<br /> detection and cause packets to be dropped in ip(6)_tunnel_xmit() or<br /> __dev_queue_xmit().<br /> <br /> Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths.<br /> <br /> In my testing, after enabling the SCTP over UDP:<br /> <br /> # ip net exec ha sysctl -w net.sctp.udp_port=9899<br /> # ip net exec ha sysctl -w net.sctp.encap_port=9899<br /> # ip net exec hb sysctl -w net.sctp.udp_port=9899<br /> # ip net exec hb sysctl -w net.sctp.encap_port=9899<br /> <br /> # ip net exec ha iperf3 -s<br /> <br /> - without this patch:<br /> <br /> # ip net exec hb iperf3 -c 192.168.0.1 --sctp<br /> [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender<br /> [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver<br /> <br /> - with this patch:<br /> <br /> # ip net exec hb iperf3 -c 192.168.0.1 --sctp<br /> [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender<br /> [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp<br /> <br /> l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding<br /> l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file<br /> acquires the lock first. A remote BLE device can send a crafted<br /> L2CAP ECRED reconfiguration response to corrupt the channel list<br /> while another thread is iterating it.<br /> <br /> Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),<br /> and l2cap_chan_unlock() and l2cap_chan_put() after, matching the<br /> pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache policy smq: fix missing locks in invalidating cache blocks<br /> <br /> In passthrough mode, the policy invalidate_mapping operation is called<br /> simultaneously from multiple workers, thus it should be protected by a<br /> lock. Otherwise, we might end up with data races on the allocated blocks<br /> counter, or even use-after-free issues with internal data structures<br /> when doing concurrent writes.<br /> <br /> Note that the existing FIXME in smq_invalidate_mapping() doesn&amp;#39;t affect<br /> passthrough mode since migration tasks don&amp;#39;t exist there, but would need<br /> attention if supporting fast device shrinking via suspend/resume without<br /> target reloading.<br /> <br /> Reproduce steps:<br /> <br /> 1. Create a cache device consisting of 1024 cache entries<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 262144 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. Populate the cache, and record the number of cached blocks<br /> <br /> fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \<br /> --size=64m --direct=1<br /> nr_cached=$(dmsetup status cache | awk &amp;#39;{split($7, a, "/"); print a[1]}&amp;#39;)<br /> <br /> 3. Reload the cache into passthrough mode<br /> <br /> dmsetup suspend cache<br /> dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"<br /> dmsetup resume cache<br /> <br /> 4. Write to the passthrough cache. By setting multiple jobs with I/O<br /> size equal to the cache block size, cache blocks are invalidated<br /> concurrently from different workers.<br /> <br /> fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \<br /> --direct=1 --numjobs=2 --randrepeat=0 --size=64m<br /> <br /> 5. Check if demoted matches cached block count. These numbers should<br /> match but may differ due to the data race.<br /> <br /> nr_demoted=$(dmsetup status cache | awk &amp;#39;{print $12}&amp;#39;)<br /> echo "$nr_cached, $nr_demoted"

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix write hang in passthrough mode<br /> <br /> The invalidate_remove() function has incomplete logic for handling write<br /> hit bios after cache invalidation. It sets up the remapping for the<br /> overwrite_bio but then drops it immediately without submission, causing<br /> write operations to hang.<br /> <br /> Fix by adding a new invalidate_committed() continuation that submits<br /> the remapped writes to the cache origin after metadata commit completes,<br /> while using the overwrite_endio hook to ensure proper completion<br /> sequencing. This maintains existing coherency. Also improve error<br /> handling in invalidate_complete() to preserve the original error status<br /> instead of using bio_io_error() unconditionally.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix null-deref with concurrent writes in passthrough mode<br /> <br /> In passthrough mode, when dm-cache starts to invalidate a cache<br /> entry and bio prison cell lock fails due to concurrent write to<br /> the same cached block, mg-&gt;cell remains NULL. The error path in<br /> invalidate_complete() attempts to unlock and free the cell<br /> unconditionally, causing a NULL pointer dereference:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT<br /> RIP: 0010:dm_cell_unlock_v2+0x3f/0x210<br /> <br /> Call Trace:<br /> invalidate_complete+0xef/0x430<br /> map_bio+0x130f/0x1a10<br /> cache_map+0x320/0x6b0<br /> __map_bio+0x458/0x510<br /> dm_submit_bio+0x40e/0x16d0<br /> __submit_bio+0x419/0x870<br /> <br /> <br /> Reproduce steps:<br /> <br /> 1. Create a cache device<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 262144 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. Promote the first data block into cache<br /> <br /> fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \<br /> --direct=1 --size=64k<br /> <br /> 3. Reload the cache into passthrough mode<br /> <br /> dmsetup suspend cache<br /> dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"<br /> dmsetup resume cache<br /> <br /> 4. Write to the first cached block concurrently<br /> <br /> fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \<br /> --randrepeat=0 --direct=1 --numjobs=2 --size 64k<br /> <br /> Fix by checking if mg-&gt;cell is valid before attempting to unlock it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sti: use managed regmap_field allocations<br /> <br /> The regmap_field objects allocated at player init are never freed and<br /> may leak resources if the driver is removed.<br /> <br /> Switch to devm_regmap_field_alloc() to automatically limit the lifetime<br /> of the allocations the lifetime of the device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sun4i: backend: fix error pointer dereference<br /> <br /> The function drm_atomic_get_plane_state() can return an error pointer<br /> and is not checked for it. Add error pointer check.<br /> <br /> Detected by Smatch:<br /> drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error:<br /> &amp;#39;plane_state&amp;#39; dereferencing possible ERR_PTR()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc<br /> <br /> pci_epf_alloc_doorbell() stores the allocated doorbell message array in<br /> epf-&gt;db_msg/epf-&gt;num_db before requesting MSI vectors. If MSI allocation<br /> fails, the array is freed but the EPF state may still point to freed<br /> memory.<br /> <br /> Clear epf-&gt;db_msg and epf-&gt;num_db on the MSI allocation failure path so<br /> that later cleanup cannot double-free the array and callers can retry<br /> allocation.<br /> <br /> Also return -EBUSY when doorbells have already been allocated to prevent<br /> leaking or overwriting an existing allocation.