Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: serialize qdisc_rtab_list against concurrent get/put<br /> <br /> qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly<br /> linked list qdisc_rtab_list and a plain non-atomic &amp;#39;int refcnt&amp;#39; with no<br /> lock. This was only safe because every caller historically held the RTNL<br /> mutex, which serialized all rate-table lookups, inserts and frees.<br /> <br /> That invariant no longer holds. cls_flower sets<br /> TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false<br /> for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through<br /> tcf_exts_validate_ex() -&gt; tcf_action_init() -&gt; tcf_action_init_1() -&gt;<br /> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the<br /> RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each<br /> adding a flower filter with a police action carrying the same rate, then<br /> race on qdisc_rtab_list and on the non-atomic refcnt, leading to a<br /> use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table.<br /> qdisc_rtab_list is a single global (not per-netns), so the corrupted<br /> object is shared system-wide.<br /> <br /> BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160<br /> qdisc_put_rtab+0x12f/0x160<br /> tcf_police_init+0xda9/0x1590<br /> tcf_action_init_1+0x460/0x6b0<br /> tcf_action_init+0x439/0xa40<br /> tcf_exts_validate_ex+0x42d/0x550<br /> fl_change+0xddd/0x7da0<br /> tc_new_tfilter+0xaa7/0x2420<br /> rtnetlink_rcv_msg+0x95e/0xe90<br /> which belongs to the cache kmalloc-2k of size 2048<br /> <br /> Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The<br /> (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before<br /> taking the lock; if a concurrent inserter added an identical table in the<br /> meantime the freshly allocated one is freed under the lock, so no<br /> duplicate is leaked. qdisc_put_rtab() now decrements the refcount and<br /> unlinks under the same lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Use sender devcom for MPV master-up<br /> <br /> After PCIe DPC recovery, mlx5 reloads the affected functions and<br /> replays multiport affiliation events. In the reported failure, the<br /> first relevant device error was:<br /> <br /> pcieport 0000:10:01.1: DPC: containment event<br /> pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal)<br /> pcieport 0000:10:01.1: [ 5] SDES (First)<br /> <br /> mlx5 recovered the PCI functions and resumed 0000:11:00.1. During<br /> that resume, RDMA multiport binding replayed<br /> MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent<br /> MPV_DEVCOM_MASTER_UP. The host then panicked with:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> RDI: 0000000000000000<br /> <br /> Call trace included:<br /> <br /> mlx5_devcom_comp_set_ready<br /> mlx5e_devcom_event_mpv<br /> mlx5_devcom_send_event<br /> mlx5_ib_bind_slave_port<br /> mlx5r_mp_probe<br /> mlx5_pci_resume<br /> <br /> MPV devcom registration publishes mlx5e private data to the component<br /> peer list before mlx5e_devcom_init_mpv() stores the returned component<br /> device in priv-&gt;devcom. A concurrent master-up event can therefore<br /> reach a peer whose private data is visible but whose priv-&gt;devcom<br /> backpointer is still NULL.<br /> <br /> MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private<br /> data as event_data. The ready bit is stored on the shared devcom<br /> component, not on an individual peer. Use the sender devcom when<br /> marking the MPV component ready.<br /> <br /> This preserves the readiness transition while avoiding a NULL<br /> dereference of the peer devcom pointer during affiliation replay after<br /> PCI error recovery.

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