Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: fix use-after-free in x25_kill_by_neigh()<br /> <br /> x25_kill_by_neigh() walks the global X.25 socket list looking for sockets<br /> attached to a terminating neighbour. x25_list_lock protects list membership<br /> while the lookup is in progress, but it does not pin a socket&amp;#39;s lifetime<br /> after the lock is dropped.<br /> <br /> The function currently drops x25_list_lock before calling lock_sock(s). A<br /> concurrent close can run x25_release(), remove the same socket from<br /> x25_list, and drop the last socket reference in that window. The neighbour<br /> teardown path can then lock or inspect a freed struct sock/struct x25_sock.<br /> <br /> Take sock_hold(s) while x25_list_lock still proves that the list entry is<br /> live, then drop the temporary reference after the socket has been locked,<br /> rechecked, and released. Recheck x25_sk(s)-&gt;neighbour after lock_sock(),<br /> because another path may have disconnected the socket before this path<br /> acquired the socket lock. Restart the list walk after each disconnect<br /> because the list lock was dropped and the previous iterator state may no<br /> longer be valid.<br /> <br /> A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in<br /> x25_kill_by_neigh().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: fix use-after-free of a severed iucv_path<br /> <br /> af_iucv queues not-yet-received message notifications on iucv-&gt;message_q,<br /> each holding a raw pointer to the connection&amp;#39;s iucv_path. When the peer<br /> severs the connection, iucv_sever_path() frees that path with<br /> iucv_path_free() but leaves the notifications queued. A later recvmsg()<br /> drains message_q via iucv_process_message_q() and hands the stale path to<br /> message_receive() -- a use-after-free of the freed iucv_path.<br /> <br /> Drop the queued notifications when the path is severed; once the path is<br /> gone they can no longer be received. This also frees the notifications<br /> leaked when a socket is closed with messages still queued.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()<br /> <br /> afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.<br /> If the allocation fails, nsk is NULL.<br /> <br /> The connection-refused path is entered when the listen state check<br /> fails, the accept backlog is full, or nsk is NULL. The code<br /> unconditionally calls iucv_sock_kill(nsk) in that path.<br /> <br /> iucv_sock_kill() does not accept a NULL socket pointer and immediately<br /> dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,<br /> calling iucv_sock_kill(nsk) results in a NULL pointer dereference.<br /> <br /> Only call iucv_sock_kill() when a child socket was successfully<br /> allocated.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: require CAP_NET_ADMIN in the device netns for changelink<br /> <br /> A tunnel changelink() operates on at most two netns, dev_net(dev) and<br /> the sticky underlay netns geneve-&gt;net. They differ once the device is<br /> created in or moved to a netns other than the one the request runs in.<br /> The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),<br /> so a caller privileged there but not in geneve-&gt;net can rewrite a geneve<br /> device whose underlay lives in geneve-&gt;net.<br /> <br /> geneve_changelink() applies the new configuration against geneve-&gt;net:<br /> geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair<br /> reopen the underlay sockets in that netns (geneve_sock_add() uses<br /> geneve-&gt;net), so the same reasoning as the tunnel changelink series<br /> applies here.<br /> <br /> Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of<br /> the op before any attribute is parsed, matching ipgre_changelink() and<br /> the rest of the "require CAP_NET_ADMIN in the device netns for<br /> changelink" series.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

*** 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.