Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: reject out-of-range ptype in ice_parser_profile_init<br /> <br /> set_bit(rslt-&gt;ptype, prof-&gt;ptypes) operates on a DECLARE_BITMAP of<br /> ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from<br /> providing ptype &gt;= 1024 through VIRTCHNL, resulting in a write past<br /> the end of the bitmap and a kernel page fault.<br /> <br /> Reproduced with a custom kernel module injecting a crafted<br /> VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),<br /> FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,<br /> kernel 7.1.0-rc1.<br /> <br /> crash_parser: ice_parser_profile_init @ ffffffffc0d61b60<br /> crash_parser: setting ptype=0xffff (max valid=1023)<br /> crash_parser: calling ice_parser_profile_init -- expect OOB crash!<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Oops: Oops: 0002 [#1] SMP NOPTI<br /> CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1<br /> Hardware name: Intel Corporation S2600BPB/S2600BPB<br /> RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]<br /> Call Trace:<br /> <br /> ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]<br /> crash_init+0x127/0xff0 [crash_parser]<br /> do_one_initcall+0x45/0x310<br /> do_init_module+0x64/0x270<br /> init_module_from_file+0xcc/0xf0<br /> idempotent_init_module+0x17b/0x280<br /> __x64_sys_finit_module+0x6e/0xe0<br /> <br /> Bail out early with -EINVAL when ptype is out of range.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> super: fix emergency thaw deadlock on frozen block devices<br /> <br /> do_thaw_all_callback() calls bdev_thaw() while holding sb-&gt;s_umount<br /> exclusively. If the block device was frozen via bdev_freeze() dropping<br /> the last block layer freeze reference calls fs_bdev_thaw() which<br /> reacquires s_umount:<br /> <br /> do_thaw_all_callback(sb)<br /> super_lock_excl(sb) # holds sb-&gt;s_umount<br /> bdev_thaw(sb-&gt;s_bdev)<br /> mutex_lock(&amp;bdev-&gt;bd_fsfreeze_mutex)<br /> # bd_fsfreeze_count drops 1 -&gt; 0<br /> bd_holder_ops-&gt;thaw == fs_bdev_thaw<br /> get_bdev_super(bdev)<br /> bdev_super_lock(bdev, true)<br /> super_lock(sb, true)<br /> down_write(&amp;sb-&gt;s_umount) # same task: deadlock<br /> <br /> The emergency thaw worker deadlocks against itself holding both<br /> s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount,<br /> freeze, or thaw of that filesystem and block device.<br /> <br /> [ 81.878470] sysrq: Show Blocked State<br /> [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000<br /> [ 81.884876] Workqueue: events do_thaw_all<br /> [ 81.886656] Call Trace:<br /> [ 81.887759] <br /> [ 81.888763] __schedule+0x579/0x1420<br /> [ 81.890372] schedule+0x3a/0x100<br /> [ 81.891794] schedule_preempt_disabled+0x15/0x30<br /> [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900<br /> [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10<br /> [ 81.896528] down_write+0xbd/0xc0<br /> [ 81.897505] super_lock+0x91/0x180<br /> [ 81.898457] ? __mutex_lock+0xa99/0x1140<br /> [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400<br /> [ 81.902069] bdev_super_lock+0x5b/0x150<br /> [ 81.903132] get_bdev_super+0x10/0x60<br /> [ 81.904042] fs_bdev_thaw+0x23/0xf0<br /> [ 81.904755] bdev_thaw+0x82/0x100<br /> [ 81.905484] do_thaw_all_callback+0x2c/0x50<br /> [ 81.906298] __iterate_supers+0x5d/0x130<br /> [ 81.907067] do_thaw_all+0x20/0x40<br /> [ 81.907739] process_one_work+0x206/0x5e0<br /> [ 81.908545] worker_thread+0x1e2/0x3c0<br /> [ 81.909339] ? __pfx_worker_thread+0x10/0x10<br /> [ 81.910171] kthread+0xf4/0x130<br /> [ 81.910799] ? __pfx_kthread+0x10/0x10<br /> [ 81.911528] ret_from_fork+0x2e2/0x3b0<br /> [ 81.912259] ? __pfx_kthread+0x10/0x10<br /> [ 81.913010] ret_from_fork_asm+0x1a/0x30<br /> [ 81.913806] <br /> <br /> bdev_super_lock() even documents the violated requirement with<br /> lockdep_assert_not_held(&amp;sb-&gt;s_umount).<br /> <br /> Acquiring bd_fsfreeze_mutex under s_umount also inverts the<br /> bd_fsfreeze_mutex vs. s_umount ordering established by<br /> bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer<br /> freeze even when the recursive path isn&amp;#39;t hit.<br /> <br /> Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin<br /> the superblock with an active reference instead as<br /> filesystems_freeze_callback() does. The active reference keeps the<br /> superblock from being shut down and so -&gt;s_bdev stays valid without<br /> holding s_umount. The block-layer-held freeze is dropped by<br /> fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as<br /> a regular unfreeze would and thaw_super_locked() handles<br /> filesystem-level freezes as before.<br /> <br /> The emergency thaw path has deadlocked like this in one form or<br /> another for a long long time but the current exclusively-held<br /> shape dates back to commit [1] where thaw_bdev() already ended in<br /> thaw_super() with s_umount held by do_thaw_all_callback().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix PTP Call Trace during PTP release<br /> <br /> If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then<br /> ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will<br /> result in the following PTP release call trace during driver unload:<br /> <br /> kernel BUG at lib/list_debug.c:52!<br /> ice_ptp_release+0x332/0x3c0 [ice]<br /> ice_deinit_features.part.0+0x10e/0x120 [ice]<br /> ice_remove+0x100/0x220 [ice]<br /> <br /> This was observed when passing PF1 through to a VM. ice_ptp_init()<br /> fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT.<br /> <br /> Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and<br /> returning without error, preventing the invalid state transition to<br /> ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from<br /> ICE_PTP_RESETTING after a failed rebuild.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ptp_s390: Add missing facility check<br /> <br /> Only register the physical clock when facility 28 is installed<br /> and PTFF QAF returns that PTFF QPT is available.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: fix Rx queue stall on alloc failure<br /> <br /> When the system is under extreme memory pressure, page allocations can<br /> fail during the Rx buffer refill loop. If the number of buffers posted<br /> to hardware falls below a critical low threshold and the refill loop<br /> exits due to allocation failures, the queue can stall:<br /> <br /> 1. The device drops incoming packets because there are no descriptors.<br /> 2. Since no packets are processed, no Rx completions are generated.<br /> 3. Because no completions occur, NAPI is never scheduled, preventing<br /> the refill loop from running again even after memory is freed.<br /> <br /> This results in a permanent queue stall.<br /> <br /> Resolve this by introducing a starvation recovery timer for each Rx queue.<br /> If the number of buffers posted to hardware falls below a critical low<br /> threshold, start a timer to periodically reschedule NAPI. Once NAPI runs<br /> and successfully refills the queue above the threshold, the timer is<br /> not rescheduled.<br /> <br /> The threshold is set to 32 because a single maximum-sized Receive Segment<br /> Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path.<br /> Lower thresholds (such as 8 or 16) would be insufficient to process a<br /> complete maximum-sized RSC packet, risking packet drops or unexpected<br /> hardware behavior under memory pressure. Setting the threshold to 32<br /> guarantees a safe margin to handle at least one full RSC packet.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: defer destroy_previous_session() until after NTLM authentication<br /> <br /> In ntlm_authenticate(), destroy_previous_session() is called using a<br /> user pointer resolved from the client-supplied NTLM blob username field<br /> before the NTLMv2 response is validated. An authenticated attacker can<br /> set the NTLM blob username to match a victim account and set<br /> PreviousSessionId to the victim&amp;#39;s session ID; destroy_previous_session()<br /> destroys the victim&amp;#39;s session while ksmbd_decode_ntlmssp_auth_blob()<br /> subsequently rejects the request with -EPERM.<br /> <br /> Move destroy_previous_session() and the prev_id assignment to after<br /> ksmbd_decode_ntlmssp_auth_blob() returns success and use sess-&gt;user<br /> rather than the pre-authentication lookup result. This matches the<br /> ordering already used by krb5_authenticate(), where<br /> destroy_previous_session() is called only after<br /> ksmbd_krb5_authenticate() returns success.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rbd: Reset positive result codes to zero in object map update path<br /> <br /> In a reply message to an RBD request, a positive result code indicates<br /> a data payload, which is not allowed for writes. While<br /> rbd_osd_req_callback() already resets a positive result code for writes<br /> to zero, rbd_object_map_callback() does not. This allows a corrupted<br /> reply to an object map update to trigger the rbd_assert(*result <br /> __rbd_obj_handle_request() and passes this positive result code. From<br /> __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which<br /> leaves the positive result code unchanged and returns true. Therefore,<br /> the if(done &amp;&amp; *result) branch is executed in __rbd_obj_handle_request()<br /> and the assertion triggers.<br /> <br /> This patch fixes the issue by adjusting the logic in the<br /> rbd_object_map_callback() path. A positive result code for an object map<br /> update is now reset to zero (similar to rbd_osd_req_callback()), and the<br /> message is subsequently handled the same way as if the result code was<br /> zero from the beginning. Additionally, a WARN_ON_ONCE() is added for<br /> this case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hip04: fix RX buffer leak on build_skb failure<br /> <br /> When build_skb() fails in hip04_rx_poll(), the driver jumps to the<br /> refill path without releasing the current RX buffer and its DMA mapping.<br /> Installing a replacement buffer then overwrites the slot references and<br /> leaks both resources.<br /> <br /> Keep the current slot intact and return budget so NAPI retries the same<br /> buffer. Also free a newly allocated RX fragment when dma_map_single()<br /> fails.<br /> <br /> This issue was found by an in-house static analysis tool.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtase: Workaround for TX hang caused by hardware packet parsing<br /> <br /> The hardware performs packet parsing before packet transmission.<br /> Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX<br /> hang because the hardware parser expects additional protocol header<br /> data that is not present in the packet.<br /> <br /> The hardware performs additional PTP parsing on UDP packets identified<br /> by destination ports 319/320 at the expected UDP destination port<br /> offset.<br /> <br /> If such a packet has transport data smaller than RTASE_MIN_PAD_LEN,<br /> the hardware parser expects additional packet data and may trigger a<br /> TX hang.<br /> <br /> To avoid these hardware issues, the driver applies the following<br /> workarounds.<br /> <br /> Drop malformed packets that may trigger this hardware issue before<br /> transmission.<br /> <br /> For IPv4 non-initial fragments, the hardware does not check the<br /> fragment offset before parsing the expected transport header location.<br /> As a result, these packets are still subject to transport header<br /> parsing even though they do not contain a transport header. If the<br /> transport data is shorter than the minimum transport header required<br /> by the hardware parser, pad the transport data to the minimum<br /> transport header length required by the hardware parser. Packets that<br /> also match the hardware PTP parsing conditions continue to follow the<br /> corresponding workaround.<br /> <br /> For IPv6 fragmented packets, neither of the above hardware issues<br /> occurs because the hardware only continues packet parsing when the<br /> IPv6 Base Header Next Header field directly indicates UDP. Packets<br /> carrying a Fragment Header do not continue through the subsequent<br /> packet parsing stages.<br /> <br /> For packets identified for hardware PTP parsing, pad the transport<br /> data so it reaches RTASE_MIN_PAD_LEN before transmission.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix peer refcount leak in TCP error paths<br /> <br /> When either the TCP RX or TX error path calls ovpn_peer_hold() followed<br /> by schedule_work(&amp;peer-&gt;tcp.defer_del_work), and the work item is already<br /> pending from the other path, schedule_work() returns false and the work<br /> runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()<br /> exactly once, the extra reference taken by the losing path is never<br /> dropped, leaking the peer object.<br /> <br /> The race window:<br /> <br /> CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error):<br /> ovpn_peer_hold()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: hold an interface reference across the scan worker<br /> <br /> mac802154_scan_worker() captures the scanning sub-interface under RCU<br /> and then keeps dereferencing sdata-&gt;dev after rcu_read_unlock() and<br /> outside the rtnl -- in the failure traces, in<br /> mac802154_transmit_beacon_req() (skb-&gt;dev = sdata-&gt;dev), and in the<br /> end_scan cleanup. Nothing keeps that netdev alive across the worker<br /> iteration.<br /> <br /> A concurrent DEL_INTERFACE or PHY removal can unregister the interface<br /> once the worker drops the rtnl between its two drv_set_channel()<br /> sections. unregister_netdevice() frees the netdev asynchronously from<br /> netdev_run_todo() with the rtnl already dropped, so neither holding the<br /> rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker<br /> iteration from dereferencing the freed netdev -- a KASAN<br /> slab-use-after-free, reachable by racing TRIGGER_SCAN against<br /> DEL_INTERFACE (both CAP_NET_ADMIN).<br /> <br /> Pin the netdev with netdev_hold() while the RCU read lock is still held,<br /> and release it at every worker exit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pppoe: reload header pointer after dev_hard_header()<br /> <br /> pppoe_sendmsg() saves a pointer to the PPPoE header before calling<br /> dev_hard_header(). Device header callbacks are allowed to reallocate the<br /> skb head, invalidating pointers into it.<br /> <br /> This can happen when a send is blocked in copy_from_user() while the first<br /> non-Ethernet port is added to an empty team device. The team&amp;#39;s delegated<br /> GRE header callback then expands the skb head. PPPoE subsequently writes<br /> six bytes through the stale pointer into the freed head.<br /> <br /> Reload the PPPoE header through the skb&amp;#39;s network-header offset after<br /> device header creation. pskb_expand_head() updates that offset when it<br /> relocates the head.