Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_reporting: use system_freezable_wq to fix UAF during suspend<br /> <br /> During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like<br /> virtio_balloon reset their underlying virtio devices and delete their<br /> virtqueues via vdev-&gt;config-&gt;del_vqs().<br /> <br /> However, page reporting work (page_reporting_process) was scheduled on the<br /> global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM<br /> freezer skips it, leaving page_reporting_process active during suspend.<br /> <br /> If pages are freed into the buddy allocator while suspending (for example,<br /> when core MM invokes the balloon shrinker during S4 hibernation image<br /> saving), page reporting triggers virtballoon_free_page_report() on deleted<br /> virtqueues, resulting in a Use-After-Free / General Protection Fault:<br /> <br /> [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI<br /> [ 196.825967] Workqueue: events page_reporting_process<br /> [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]<br /> [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]<br /> [ 196.946943] page_reporting_process+0x370/0x4f0<br /> <br /> Fix this by switching page reporting work to system_freezable_wq. This<br /> ensures that the PM freezer pauses page_reporting_process before device<br /> drivers destroy their reporting virtqueues. Because the reporting worker<br /> is frozen, memory reclamation/freeing (e.g. via shrinker execution) can<br /> safely return pages to MM during freeze without triggering unfrozen<br /> reporting work on deleted virtqueues.<br /> <br /> This aligns with the driver&amp;#39;s existing design. The comment in<br /> virtballoon_freeze() states:<br /> /*<br /> * The workqueue is already frozen by the PM core before this<br /> * function is called.<br /> */<br /> <br /> Testing:<br /> I have verified these fixes using Google’s virtualization infrastructure<br /> by running continuous suspend/resume iterations (40+ cycles) while<br /> churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60%<br /> --timeout 1`) to constantly create free pages for the buddy allocator. We<br /> also set the `page_reporting_order` parameter to 0 to make the page<br /> reporting worker highly sensitive, forcing it to pick up any 4K free<br /> pages. This confirmed that the UAF crashes are no longer reproducible.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix skb leak on flow key update failure during ct<br /> <br /> ovs_ct_execute() always steals or frees the skb on failure while<br /> ovs_flow_key_update() does not. So, if it fails and we return right<br /> away, the skb ends up leaked.<br /> <br /> Fix that by breaking instead and letting the common error handling<br /> code at the bottom of the loop to free the skb properly.<br /> <br /> This is a very unlikely scenario as it requires the packet to become<br /> unparseable by applying a set of actions on a previously parseable skb,<br /> but should be fixed nevertheless.<br /> <br /> Reported by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix potential UAF on meter attach failure<br /> <br /> While attaching a newly created meter attach_meter() function makes<br /> the new meter visible to other CPUs but can still fail afterwards.<br /> On failure, it detaches the meter back and returns an error.<br /> <br /> However, this is an unexpected behavior for the ovs_meter_cmd_set()<br /> that uses a plain kfree(meter) on attach failure without waiting for<br /> RCU readers to stop using it, assuming it was never visible.<br /> <br /> This is never a problem for ovs-vswitchd as it always creates meters<br /> before creating any flows that use them. But the UAF can be triggered<br /> with a custom application using uAPI:<br /> <br /> BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653)<br /> Read of size 8 at addr ffff88810d152650 by task meter/2508<br /> <br /> Call Trace:<br /> ovs_meter_execute (net/openvswitch/meter.c:653)<br /> do_execute_actions (net/openvswitch/actions.c:1407)<br /> ovs_execute_actions (net/openvswitch/actions.c:1584)<br /> ovs_packet_cmd_execute (net/openvswitch/datapath.c:703)<br /> ...<br /> netlink_sendmsg (af_netlink.c:1900)<br /> <br /> Allocated by task 2519:<br /> __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)<br /> ovs_meter_cmd_set (net/openvswitch/meter.c:422)<br /> ...<br /> netlink_sendmsg (af_netlink.c:1900)<br /> <br /> Freed by task 2519:<br /> kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720)<br /> ovs_meter_cmd_set (net/openvswitch/meter.c:479)<br /> ...<br /> netlink_sendmsg (af_netlink.c:1900)<br /> <br /> Fix that by making sure attach_meter() doesn&amp;#39;t make the meter visible<br /> until all the checks are done and the function can&amp;#39;t fail anymore.<br /> <br /> This also makes sure the "hash" value is calculated after the potential<br /> re-sizing of the table.<br /> <br /> Reported by Trend Micro&amp;#39;s Zero Day Initiative as ZDI-CAN-31642.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Close speculative mem read possibility<br /> <br /> The domain value is extracted from a given CCA or EP11 ioctl struct<br /> when a CPRB is about to be sent. Thus this is a user controlled value.<br /> Under some special conditions (custom device node used, administrative<br /> load) this value is used as an array index after bounds checking, but<br /> without speculation barrier.<br /> <br /> Add the missing array_index_nospec() call to prevent speculative<br /> execution where this domain value is used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: Check CAP_NET_ADMIN for private ioctls<br /> <br /> Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL,<br /> SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN<br /> capable check to ensure unprivileged users cannot invoke them.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: pch: use raw_spinlock_t for the register lock<br /> <br /> pch_irq_type() is registered as the irq_chip .irq_set_type callback and<br /> takes chip-&gt;spinlock with spin_lock_irqsave(). This callback is reached<br /> from __setup_irq() -&gt; __irq_set_trigger() -&gt; chip-&gt;irq_set_type() while<br /> the caller holds desc-&gt;lock, a raw_spinlock_t, with hardirqs disabled.<br /> That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is<br /> an rtmutex-backed sleeping lock, so acquiring it there is invalid.<br /> <br /> This was confirmed on a PREEMPT_RT kernel with lockdep<br /> (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored<br /> pch_irq_type()&amp;#39;s locking and drove it through the real genirq carrier<br /> irq_set_irq_type() -&gt; __irq_set_trigger() -&gt; chip-&gt;irq_set_type(), i.e.<br /> the same __irq_set_trigger() edge that __setup_irq() takes for a<br /> requested IRQ. With the original spin_lock_irqsave() edge lockdep<br /> reported an invalid wait context, immediately followed by:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod<br /> hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60<br /> rt_spin_lock+0x3a/0x1c0<br /> repro_irq_set_type+0x64/0xa0 [pch_repro]<br /> __irq_set_trigger+0x69/0x140<br /> irq_set_irq_type+0x78/0xd0<br /> <br /> Switching the mirrored lock to raw_spinlock_t made both splats go away.<br /> <br /> Convert the register lock to raw_spinlock_t. The same lock also<br /> serializes the GPIO direction/value callbacks and the suspend/resume<br /> register save/restore, but all of those critical sections only perform<br /> MMIO register accesses (ioread32()/iowrite32()) and<br /> irq_set_handler_locked(); none of them contain sleepable operations.<br /> Keeping this register lock non-sleeping is therefore appropriate for the<br /> irqchip callbacks and does not change the GPIO-side locking contract.<br /> <br /> This is the same class of issue and fix as recently addressed for other<br /> GPIO controllers, e.g. commit 286533cb14a3 ("gpio: sch: use raw_spinlock_t<br /> in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use<br /> raw_spinlock_t in the irq startup path").

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: prevent peer transport count overflow<br /> <br /> sctp_assoc_add_peer() increments the association&amp;#39;s 16-bit transport_count<br /> for every new unique peer. Adding the 65,536th transport wraps the count to<br /> zero.<br /> <br /> SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload,<br /> then copies one sockaddr_storage for every entry in transport_addr_list.<br /> After the wrap, a diagnostic dump reserves an empty payload and writes<br /> 8 MiB of peer addresses past the skb tail.<br /> <br /> Reject a new unique peer when transport_count has reached U16_MAX. Perform<br /> the check after the existing-peer lookup so a duplicate address continues<br /> to return its existing transport at the limit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write<br /> <br /> resp_report_zones() sizes the reply buffer from the CDB allocation<br /> length. The v3 fix rounds alloc_len up with ALIGN() before deriving the<br /> descriptor count:<br /> <br /> rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) -<br /> RZONES_DESC_HD) &gt;&gt; ilog2(RZONES_DESC_HD);<br /> arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1);<br /> <br /> For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to<br /> 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()&amp;#39;s size_t is 32-bit<br /> and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which<br /> passes the !arr check, and desc = arr + 64 is then dereferenced in the<br /> loop -&gt; out-of-bounds write / panic.<br /> <br /> Clamp rep_max_zones to devip-&gt;nr_zones. The loop already stops at<br /> sdebug_capacity (after nr_zones zones), so a report can never hold more<br /> than nr_zones descriptors; the clamp does not change the report, it only<br /> bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device<br /> property that can never reach 0x100000000.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Check return value of __register_event() in trace_module_add_events()<br /> <br /> trace_module_add_events() ignores the return value of __register_event()<br /> and unconditionally calls __add_event_to_tracers() for each event.<br /> <br /> If __register_event() fails (for example, if event_init() fails), the<br /> trace_event_call is not added to ftrace_events list, but<br /> __add_event_to_tracers() still creates a trace_event_file pointing to it.<br /> If module loading subsequently fails and module memory is freed, tracing<br /> state retains a stale trace_event_call pointer in trace_event_file,<br /> leading to a use-after-free when tracefs or tracing subsystem operations<br /> are later executed.<br /> <br /> Fix this by checking the return value of __register_event() and only<br /> calling __add_event_to_tracers() if event registration succeeded.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()<br /> <br /> ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into<br /> ub-&gt;dev_info and then fixes up the fields the driver owns, but misses<br /> -&gt;state and -&gt;ublksrv_pid.<br /> <br /> A device added with -&gt;state = UBLK_S_DEV_LIVE passes the<br /> "-&gt;state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its<br /> proxy for "a disk is attached", while -&gt;ub_disk is still NULL, so DEL_DEV<br /> right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus<br /> UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A<br /> poisoned -&gt;state also gets START_USER_RECOVERY and the char device<br /> read/write path onto a device that was never started, and wedges START_DEV<br /> at -EEXIST. A poisoned -&gt;ublksrv_pid just makes GET_DEV_INFO report an<br /> unrelated task as the ublk server.<br /> <br /> Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only<br /> ever reads these back, so correcting them silently breaks nothing.<br /> <br /> ADD_DEV has copied -&gt;state in unsanitized since ublk was merged, but back<br /> then it was harmless: the gendisk was allocated during ADD_DEV, and both<br /> teardown and the START_DEV -EEXIST check keyed off disk_live() rather than<br /> -&gt;state. The oops became reachable once the disk allocation moved to<br /> START_DEV and those checks switched to -&gt;state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size<br /> <br /> vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB<br /> binner BO, but writes the size of the whole BO to BPOS. On every binner<br /> out-of-memory event the PTB is therefore authorized to write tile lists<br /> across all the other slots (which may hold the tile state, tile alloc and<br /> overflow memory of in-flight jobs) and, for any slot but the first, past<br /> the end of the binner BO into unrelated CMA memory.<br /> <br /> Since CMA pages are recycled into page cache and user allocations, this<br /> is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU<br /> hangs with corrupted control list pointers, userspace heap corruption, a<br /> GPU that stays permanently wedged after the first hang, and occasional<br /> full system crashes, whenever a job overflows the initial binner slot.<br /> <br /> The bug dates back to the conversion from a dedicated overflow BO (where<br /> writing the full BO size was correct) to the slotted binner BO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: peak_usb: validate uCAN receive record lengths<br /> <br /> pcan_usb_fd_decode_buf() walks uCAN records packed in one USB<br /> receive buffer.<br /> <br /> Require each record to contain the fixed header for its type, and verify<br /> CAN payload bytes before copying them into the skb.