Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: make ebt_snat ARP rewrite writable<br /> <br /> The ebtables SNAT target keeps the Ethernet source address rewrite<br /> behind skb_ensure_writable(skb, 0). This is intentional: at the bridge<br /> ebtables hooks the Ethernet header is addressed through<br /> skb_mac_header()/eth_hdr(), while skb-&gt;data points at the Ethernet<br /> payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check<br /> the payload, not the Ethernet header, and would reintroduce the small<br /> packet regression fixed by commit 63137bc5882a.<br /> <br /> However, the optional ARP sender hardware address rewrite is different.<br /> It writes through skb_store_bits() at an offset relative to skb-&gt;data:<br /> <br /> skb_store_bits(skb, sizeof(struct arphdr), info-&gt;mac, ETH_ALEN)<br /> <br /> skb_header_pointer() only safely reads the ARP header; it does not make<br /> the later sender hardware address range writable. If that range is<br /> still held in a nonlinear skb fragment backed by a splice-imported file<br /> page, skb_store_bits() maps the frag page and copies the new MAC address<br /> directly into it.<br /> <br /> Ensure the ARP SHA range is writable before reading the ARP header and<br /> before calling skb_store_bits().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache policy smq: check allocation under invalidate lock<br /> <br /> commit 2d1f7b65f5de ("dm cache policy smq: fix missing locks in<br /> invalidating cache blocks") added mq-&gt;lock around the destructive part of<br /> smq_invalidate_mapping(), but left the e-&gt;allocated check outside the<br /> critical section.<br /> <br /> That leaves a check-then-act race. Two concurrent invalidators can both<br /> observe e-&gt;allocated as true before either of them takes mq-&gt;lock. The<br /> first invalidator that acquires the lock removes the entry from the<br /> queues and hash table and then calls free_entry(), which clears<br /> e-&gt;allocated and puts the entry back on the free list. The second<br /> invalidator can then acquire mq-&gt;lock and continue with the stale result<br /> of the unlocked check.<br /> <br /> This can corrupt the SMQ queues or hash table by deleting an entry that<br /> is no longer on those structures. It can also hit the allocation check in<br /> free_entry() when the same entry is freed again.<br /> <br /> Move the allocation check under mq-&gt;lock so the predicate and the<br /> destructive operations are serialized by the same lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 6lowpan: fix off-by-one in multicast context address compression<br /> <br /> The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses<br /> &amp;data[1] as destination and &amp;ipaddr-&gt;s6_addr[11] as source, but<br /> both should be offset by one: &amp;data[2] and &amp;ipaddr-&gt;s6_addr[12]<br /> respectively.<br /> <br /> This off-by-one has two consequences:<br /> 1. data[1] is overwritten with s6_addr[11], corrupting the RIID<br /> field in the compressed multicast address<br /> 2. data[5] is never written, so uninitialized kernel stack memory<br /> is transmitted over the network via lowpan_push_hc_data(),<br /> leaking kernel stack contents<br /> <br /> The correct inline data layout must match what the decompression<br /> function lowpan_uncompress_multicast_ctx_daddr() expects:<br /> data[0..1] = s6_addr[1..2] (flags/scope + RIID)<br /> data[2..5] = s6_addr[12..15] (group ID)<br /> <br /> Also zero-initialize the data array as a defensive measure against<br /> similar bugs in the future.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()<br /> <br /> pppol2tp_ioctl() read sock-&gt;sk-&gt;sk_user_data directly without any<br /> locks or reference counting. If a controllable sleep was induced during<br /> copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent<br /> socket close could trigger pppol2tp_session_close() asynchronously. This<br /> frees the l2tp_session structure via the l2tp_session_del_work workqueue.<br /> Upon resuming, the ioctl thread dereferences the stale session pointer,<br /> resulting in a Use-After-Free (UAF).<br /> <br /> Fix this by securely fetching the session reference using the RCU-safe,<br /> refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the<br /> session&amp;#39;s refcount across the sleep. We structured the function to exit<br /> via standard err breaks, guaranteeing that l2tp_session_put() is cleanly<br /> called on all return paths to drop the reference.<br /> <br /> To preserve existing behavior we validate the session and its magic<br /> signature only for the specific L2TP commands that require it. This<br /> ensures that generic/unknown ioctls called on an unconnected socket<br /> still return -ENOIOCTLCMD and correctly fall back to generic handlers<br /> (e.g. in sock_do_ioctl()).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: Release nested relation on devlink free<br /> <br /> devlink relation state is normally released from devl_unregister(), which<br /> calls devlink_rel_put(). This misses devlink instances that get a nested<br /> relation before registration and then fail probe before devl_register() is<br /> reached.<br /> <br /> That flow can happen for SFs. The child devlink gets linked to its<br /> parent before registration, then a later probe error calls devlink_free()<br /> directly. Since the instance was never registered, devl_unregister() is not<br /> called and devlink-&gt;rel is leaked.<br /> <br /> Release any pending relation from devlink_free() as well. The registered<br /> path is unchanged because devl_unregister() already clears devlink-&gt;rel<br /> before devlink_free() runs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: use RCU with deferred freeing for action lifecycle<br /> <br /> When NEWTFILTER and DELFILTER are run concurrently it is possible to create a<br /> race with an associated action.<br /> <br /> Let&amp;#39;s illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:<br /> <br /> 0: mutex_lock()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: anycast: insert aca into global hash under idev-&gt;lock<br /> <br /> syzbot reported a splat [1]: a slab-use-after-free in<br /> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash<br /> under RCU and dereferences a struct ifacaddr6 that has already been<br /> freed while still linked in the hash, so a later reader walks into a<br /> dangling node.<br /> <br /> In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then<br /> aca_get() bumps it to 2 to keep it alive across the unlocked region.<br /> It is published to idev-&gt;ac_list under idev-&gt;lock, but<br /> ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent<br /> teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL)<br /> can slip into that window:<br /> <br /> CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL)<br /> ------------------------------ ------------------------------------<br /> aca_alloc() refcnt 1<br /> aca_get() refcnt 2<br /> write_lock_bh(idev-&gt;lock)<br /> add aca to ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> write_lock_bh(idev-&gt;lock)<br /> pull aca off ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> ipv6_del_acaddr_hash(aca)<br /> hlist_del_init_rcu() is a no-op,<br /> aca is not in the hash yet<br /> aca_put() refcnt 2-&gt;1<br /> ipv6_add_acaddr_hash(aca)<br /> aca now inserted into the hash<br /> aca_put() refcnt 1-&gt;0<br /> call_rcu(aca_free_rcu) -&gt; kfree(aca)<br /> <br /> The hash removal becomes a no-op because the insertion has not<br /> happened yet, so once CPU0 inserts and drops the last reference, the<br /> aca is freed while still linked in inet6_acaddr_lst[], and readers<br /> dereference freed memory after the slab slot is reused.<br /> <br /> This window opened once RTNL stopped serializing the join path against<br /> device teardown. Move ipv6_add_acaddr_hash() inside the idev-&gt;lock<br /> section so the ac_list and hash insertions are atomic with respect to<br /> teardown: a racing remover now either misses the aca entirely or finds<br /> it in both lists.<br /> <br /> acaddr_hash_lock is now nested under idev-&gt;lock, which is acquired in<br /> softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh()<br /> to avoid the irq lock inversion reported in [2].<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a<br /> [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: fix leak if split 6 GHz scanning fails<br /> <br /> rdev-&gt;int_scan_req is leaked if cfg80211_scan() fails. Note that it&amp;#39;s<br /> supposed to be released at ___cfg80211_scan_done() but this doesn&amp;#39;t happen<br /> as rdev-&gt;scan_req is NULL at that point, too, leading to the early return<br /> from the freeing function.<br /> <br /> unreferenced object 0xffff8881161d0800 (size 512):<br /> comm "wpa_supplicant", pid 379, jiffies 4294749765<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................<br /> backtrace (crc c867fdb6):<br /> kmemleak_alloc+0x89/0x90<br /> __kmalloc_noprof+0x2fd/0x410<br /> cfg80211_scan+0x133/0x730<br /> nl80211_trigger_scan+0xc69/0x1cc0<br /> genl_family_rcv_msg_doit+0x204/0x2f0<br /> genl_rcv_msg+0x431/0x6b0<br /> netlink_rcv_skb+0x143/0x3f0<br /> genl_rcv+0x27/0x40<br /> netlink_unicast+0x4f6/0x820<br /> netlink_sendmsg+0x797/0xce0<br /> __sock_sendmsg+0xc4/0x160<br /> ____sys_sendmsg+0x5e4/0x890<br /> ___sys_sendmsg+0xf8/0x180<br /> __sys_sendmsg+0x136/0x1e0<br /> __x64_sys_sendmsg+0x76/0xc0<br /> x64_sys_call+0x13f0/0x17d0<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: enforce HE/EHT cap/oper consistency<br /> <br /> Xiang Mei reports that mac80211 could crash if eht_cap is set<br /> but eht_oper isn&amp;#39;t. Rather than fixing that for the individual<br /> user(s), enforce that both HE/EHT have consistent elements.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()<br /> <br /> rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,<br /> but returns the selected listener after dropping that lock without<br /> taking a reference. rfcomm_connect_ind() then locks the listener,<br /> queues a child socket on it, and may notify it after unlocking it.<br /> <br /> The buggy scenario involves two paths, with each column showing the<br /> order within that path:<br /> <br /> rfcomm_connect_ind(): listener close:<br /> 1. Find parent in 1. close() enters<br /> rfcomm_get_sock_by_channel() rfcomm_sock_release().<br /> 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown()<br /> without pinning parent. closes the listener.<br /> 3. Call lock_sock(parent) and 3. rfcomm_sock_kill()<br /> bt_accept_enqueue(parent, unlinks and puts parent.<br /> sk, true).<br /> 4. Read parent flags and may 4. parent can be freed.<br /> call sk_state_change().<br /> <br /> If close wins the race, parent can be freed before<br /> rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the<br /> deferred-setup callback.<br /> <br /> Take a reference on the listener before leaving rfcomm_sk_list.lock.<br /> After lock_sock() succeeds, recheck that it is still in BT_LISTEN<br /> before queueing a child, cache the deferred-setup bit while the parent<br /> is locked, and drop the reference after the last parent use.<br /> <br /> KASAN reported a slab-use-after-free in lock_sock_nested() from<br /> rfcomm_connect_ind(), with the freeing stack going through<br /> rfcomm_sock_kill() and rfcomm_sock_release().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: validate advertising TLV before type checks<br /> <br /> tlv_data_is_valid() reads each advertising data field length from<br /> data[i], then inspects data[i + 1] for managed EIR types before<br /> checking that the current field still fits inside the supplied buffer.<br /> <br /> A malformed field whose length byte is the last byte of the buffer can<br /> therefore make the parser read one byte past the advertising data.<br /> <br /> KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING<br /> request reached that path:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()<br /> Read of size 1<br /> Call trace:<br /> tlv_data_is_valid()<br /> add_advertising()<br /> hci_mgmt_cmd()<br /> hci_sock_sendmsg()<br /> <br /> Move the existing element-length check before any type-octet inspection<br /> so each non-empty element is proven to contain its type byte before the<br /> parser looks at data[i + 1].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: validate skb length in MCC handlers<br /> <br /> The RFCOMM MCC handlers cast skb-&gt;data to protocol-specific structs<br /> without validating skb-&gt;len first. A malicious remote device can send<br /> truncated MCC frames and trigger out-of-bounds reads in these handlers.<br /> <br /> Fix this by using skb_pull_data() to validate and access the required<br /> data before dereferencing it.<br /> <br /> rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows<br /> 1-byte RPN requests. Handle this by validating only the DLCI byte first,<br /> and validating the full struct only when len &gt; 1.