Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: skip sync_blockdev() on surprise removal in bdev_mark_dead()<br /> <br /> bdev_mark_dead()&amp;#39;s @surprise == true means the device is already gone.<br /> The filesystem callback fs_bdev_mark_dead() honours this and skips<br /> sync_filesystem(), but the bare block device path (no -&gt;mark_dead op)<br /> lost its !surprise guard when the holder -&gt;mark_dead callback was wired<br /> up (see Fixes), and now calls sync_blockdev() unconditionally, which can<br /> hang forever waiting on writeback that can no longer complete.<br /> <br /> syzkaller hit this via nvme_reset_work()&amp;#39;s "I/O queues lost" path:<br /> nvme_mark_namespaces_dead() -&gt; blk_mark_disk_dead() -&gt;<br /> bdev_mark_dead(bdev, true) -&gt; sync_blockdev() blocks in<br /> folio_wait_writeback(), wedging the reset worker and every task waiting<br /> on it.<br /> <br /> Skip the sync on surprise removal, matching fs_bdev_mark_dead();<br /> invalidate_bdev() still runs. Orderly removal (surprise == false) is<br /> unchanged.<br /> <br /> Found by FuzzNvme(Syzkaller with FEMU fuzzing framework).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Initialize epfile-&gt;in early to fix endpoint direction checks<br /> <br /> When parsing endpoint descriptors, ffs_data_got_descs() generates the<br /> eps_addrmap which contains the endpoint direction. However, epfile-&gt;in<br /> was previously only populated in ffs_func_eps_enable() which executes<br /> upon USB host connection. As a result, early userspace ioctls like<br /> FUNCTIONFS_DMABUF_ATTACH that run before the host connects would see<br /> epfile-&gt;in as 0, leading to incorrect DMA directions.<br /> <br /> By moving the initialization to ffs_epfiles_create(), epfile-&gt;in is<br /> accurate before userspace opens the endpoint files.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Fix DMA fence leak<br /> <br /> In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc&amp;#39;d, with the<br /> underlying dma_fence later initialized by dma_fence_init(), which sets<br /> its kref counter to 1. Then, dma_resv_add_fence() gets a second<br /> reference, and a pointer to the ffs_dma_fence is passed as the<br /> usb_request&amp;#39;s "context" field.<br /> <br /> The dma-resv mechanism will manage the second reference, but the first<br /> reference is never properly released; the ffs_dmabuf_cleanup() function<br /> decreases the reference count, but only to balance with the reference<br /> grab in ffs_dmabuf_signal_done().<br /> <br /> The code will then slowly leak memory as more ffs_dma_fence objects are<br /> created without being ever freed.<br /> <br /> Address this issue by transferring ownership of the fence to the DMA<br /> reservation object, by calling dma_fence_put() right after<br /> dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded<br /> after being signalled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove<br /> <br /> The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(),<br /> which on a connector-change event calls ucsi_connector_change() and<br /> schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees<br /> uc-&gt;ucsi (kfree) before free_irq() is called, so a handler invocation<br /> already in flight may access the freed object after ucsi_destroy().<br /> <br /> CPU 0 (remove) | CPU 1 (threaded IRQ)<br /> ucsi_destroy(uc-&gt;ucsi) | ccg_irq_handler()<br /> kfree(ucsi) // FREE | ucsi_notify_common(uc-&gt;ucsi) // USE<br /> <br /> Move free_irq() before ucsi_destroy() in the remove path. It is kept<br /> after ucsi_unregister(): ucsi_unregister() cancels connector work whose<br /> handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(),<br /> which waits for a completion that is signalled from the IRQ handler, so<br /> the IRQ must stay active until that work has been cancelled.<br /> <br /> The probe error path already orders free_irq() before ucsi_destroy().<br /> <br /> This bug was found by static analysis.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: Validate SVID index in svdm_consume_modes()<br /> <br /> In svdm_consume_modes(), the SVID value is read from pmdata-&gt;svids using<br /> pmdata-&gt;svid_index as an array index without bounds validation:<br /> <br /> paltmode-&gt;svid = pmdata-&gt;svids[pmdata-&gt;svid_index];<br /> <br /> If pmdata-&gt;svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results<br /> in an out-of-bounds read of the pmdata-&gt;svids array. Because pd_mode_data<br /> is embedded inside struct tcpm_port, indexing past svids reads into<br /> adjacent fields. In particular:<br /> - At index 16, it reads the altmodes count.<br /> - At index 18 and beyond, it reads into altmode_desc[], which contains<br /> partner-supplied SVDM Discovery Modes VDOs.<br /> <br /> By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index<br /> to 20, the partner can force paltmode-&gt;svid to be loaded with an arbitrary,<br /> partner- chosen SVID, which is then registered via<br /> typec_partner_register_altmode().<br /> <br /> Fix this by validating that pmdata-&gt;svid_index is non-negative and strictly<br /> less than pmdata-&gt;nsvids before accessing the pmdata-&gt;svids array inside<br /> svdm_consume_modes().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: vudc: fix NULL deref in vep_dequeue()<br /> <br /> vep_alloc_request() wasn&amp;#39;t initializing vrequest-&gt;udc, so cancellations<br /> on the FunctionFS AIO path were arriving in vep_dequeue without a valid<br /> UDC reference.<br /> <br /> Since vrequest-&gt;udc is never actually properly used anywhere, we opt to<br /> remove it, and update vep_dequeue to obtain a reference to the udc with<br /> ep_to_vudc(), consistent with the other vep_ ops.<br /> <br /> AFAICT this bug has existed for ~10 years. Seems that nobody has really<br /> stressed the FunctionFS AIO path on usbip&amp;#39;s vudc.<br /> <br /> I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints<br /> via AIO. Before the fix, running `usbip attach` from the host would<br /> cause the guest to oops with the following backtrace:<br /> <br /> Call trace:<br /> vep_dequeue+0x1c/0xe4 (P)<br /> usb_ep_dequeue+0x14/0x20<br /> ffs_aio_cancel+0x24/0x34<br /> __arm64_sys_io_cancel+0xb0/0x124<br /> do_el0_svc+0x68/0x100<br /> el0_svc+0x18/0x5c<br /> el0t_64_sync_handler+0x98/0xdc<br /> el0t_64_sync+0x154/0x158

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: ulpi: fix memory leak on registration failure<br /> <br /> The allocated device name is never freed on early ULPI device<br /> registration failures.<br /> <br /> Fix this by initialising the device structure earlier and releasing the<br /> initial reference whenever registration fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: target: rdma: fix ndev refcount leak on queue connect<br /> <br /> nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which<br /> acquires a reference on the returned ndev via kref_get(). On the path<br /> where the host queue backlog is exceeded and the function returns<br /> NVME_SC_CONNECT_CTRL_BUSY, reference of ndev is not released, leaking<br /> the kref.<br /> <br /> Fix this by adding a goto to the existing put_device label before the<br /> early return.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: bound Rock Ridge symlink components to the SL record<br /> <br /> get_symlink_chunk() and the SL handling in<br /> parse_rock_ridge_inode_internal() walk the variable-length components of<br /> a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte<br /> header (flags, len) followed by len bytes of text, so it occupies<br /> slp-&gt;len + 2 bytes. Both loops read slp-&gt;len and advance to the next<br /> component, and get_symlink_chunk() additionally does<br /> memcpy(rpnt, slp-&gt;text, slp-&gt;len), but neither checks that the component<br /> lies within the SL record before dereferencing it.<br /> <br /> A crafted SL record whose component declares a len that runs past the<br /> record (rr-&gt;len) therefore triggers an out-of-bounds read of up to 255<br /> bytes. When the record sits at the tail of its backing buffer - for<br /> example a small kmalloc()ed continuation block reached through a CE<br /> record - the read crosses the allocation; get_symlink_chunk() then<br /> copies the out-of-bounds bytes into the symlink body returned to user<br /> space by readlink(), disclosing adjacent kernel memory.<br /> <br /> ISO 9660 images are routinely mounted from untrusted removable media -<br /> desktop environments auto-mount them (e.g. via udisks2) without<br /> CAP_SYS_ADMIN - so the record contents are attacker-controlled.<br /> <br /> Reject any component that does not fit in the remaining record bytes<br /> before using it. In get_symlink_chunk() return NULL, like the existing<br /> output-buffer (plimit) checks, so a malformed record makes readlink()<br /> fail with -EIO rather than silently returning a truncated target; in<br /> parse_rock_ridge_inode_internal() stop the inode-size walk.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> partitions: aix: bound the pp_count scan to the ppe array<br /> <br /> aix_partition() reads the physical volume descriptor into a fixed-size<br /> struct pvd and then scans its physical-partition-extent array:<br /> <br /> int numpps = be16_to_cpu(pvd-&gt;pp_count);<br /> ...<br /> for (i = 0; i ppe + i;<br /> ...<br /> lp_ix = be16_to_cpu(p-&gt;lp_ix);<br /> <br /> pvd points at a single kmalloc()&amp;#39;d struct pvd whose ppe[] member holds a<br /> fixed ARRAY_SIZE(pvd-&gt;ppe) (1016) entries, but the loop runs up to the<br /> on-disk pp_count. pp_count is an unvalidated __be16 read straight from<br /> the descriptor, so a crafted AIX image with pp_count larger than 1016<br /> drives the loop to read pvd-&gt;ppe[i] past the end of the allocation (up<br /> to 65535 entries, ~2 MB out of bounds).<br /> <br /> The partition scan runs without mounting anything, when a block device<br /> with a crafted AIX/IBM partition table appears (an attacker-supplied<br /> image attached with losetup -P, or a device auto-scanned by udev), via<br /> msdos_partition() -&gt; aix_partition().<br /> <br /> Clamp the scan to the number of entries the ppe[] array can hold.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-auth: validate reply message payload bounds against transfer length<br /> <br /> nvmet_auth_reply() accesses the variable-length rval[] array using<br /> attacker-controlled hl (hash length) and dhvlen (DH value length) fields<br /> without verifying they fit within the allocated buffer of tl bytes.<br /> <br /> A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a<br /> small transfer length but large hl/dhvlen values, causing out-of-bounds<br /> heap reads when the target processes the DH public key (rval + 2*hl) or<br /> performs the host response memcmp.<br /> <br /> With DH authentication configured, the OOB pointer is passed directly to<br /> sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching<br /> up to 526 bytes past the buffer. This is exploitable pre-authentication.<br /> <br /> Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page<br /> <br /> nvmet_execute_disc_get_log_page() validates only the dword alignment<br /> of the host-supplied Log Page Offset (lpo). The 64-bit offset is then<br /> added to a small kzalloc&amp;#39;d buffer that holds the discovery log page<br /> and the result is passed straight to nvmet_copy_to_sgl(), which<br /> memcpy()s data_len bytes out to the host with no source-side bound<br /> check:<br /> <br /> u64 offset = nvmet_get_log_page_offset(req-&gt;cmd); /* 64-bit host */<br /> size_t data_len = nvmet_get_log_page_len(req-&gt;cmd); /* 32-bit host */<br /> ...<br /> if (offset &amp; 0x3) { ... } /* only check */<br /> ...<br /> alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);<br /> buffer = kzalloc(alloc_len, GFP_KERNEL);<br /> ...<br /> status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);<br /> <br /> The Discovery controller is unauthenticated -- nvmet_host_allowed()<br /> returns true unconditionally for the discovery subsystem -- so the call<br /> is reachable pre-authentication by any TCP/RDMA/FC peer that can reach<br /> the nvmet target. With a discovery log page of ~1 KiB, an attacker<br /> requesting up to 4 KiB starting at offset == alloc_len reads the next<br /> slab page out and gets its content returned over the fabric (an<br /> empirical run on a default nvmet-tcp loopback target leaked 81<br /> canonical kernel pointers in one Get Log Page response). Pointing the<br /> offset at unmapped kernel memory faults the in-kernel memcpy and<br /> crashes (or panics, on panic_on_oops=1) the target host instead.<br /> <br /> The attacker-controlled source-side offset pattern<br /> "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique<br /> to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every<br /> other Get Log Page handler in admin-cmd.c either ignores lpo (and<br /> silently starts every response at offset 0) or tracks a local<br /> destination offset with a fixed source pointer.<br /> <br /> Validate the host-supplied offset against the log page size, cap the<br /> copy length to what is actually available, and zero-fill any remainder<br /> of the host transfer buffer. The zero-fill matches the existing<br /> short-response pattern in nvmet_execute_get_log_changed_ns()<br /> (admin-cmd.c) and prevents leaking transport SGL contents when the<br /> host asks for more bytes than the log page contains.