Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Cap AEAD AD length to 0x80000000<br /> <br /> In order to prevent arithmetic overflows when checking the TX<br /> buffer size, cap the associated data length to 0x80000000.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Drop CLONE_THREAD requirement for private default hash alloc<br /> <br /> Currently need_futex_hash_allocate_default() depends on strict pthread<br /> semantics, abusing CLONE_THREAD. This breaks the non-concurrency<br /> assumptions when doing the mm-&gt;futex_ref pcpu allocations, leading to<br /> bugs[0] when sharing the mm in other ways; ie:<br /> <br /> BUG: KASAN: slab-use-after-free in futex_hash_put<br /> <br /> ... where the +1 bias can end up on a percpu counter that mm-&gt;futex_ref<br /> no longer points at.<br /> <br /> Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding<br /> vfork keeps the existing paths untouched (no overhead), and we can&amp;#39;t<br /> race in the first place: either the parent is suspended and the child<br /> runs alone, or mm-&gt;futex_ref is already allocated from an earlier<br /> CLONE_VM.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans<br /> <br /> The USB MIDI 2.0 endpoint parser has the same descriptor walking<br /> pattern as the legacy MIDI parser. It validates bLength against<br /> bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> A malformed device can therefore make later baAssoGrpTrmBlkID[] reads<br /> consume bytes past the walked descriptor.<br /> <br /> Reject zero-length and overlong descriptors while walking endpoint<br /> extras.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Bound MIDI endpoint descriptor scans<br /> <br /> snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint<br /> descriptor size before using baAssocJackID[], but the descriptor walker can<br /> still return a class-specific endpoint descriptor whose bLength exceeds the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> That leaves later flexible-array reads bounded by bLength, but not by the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> Stop walking when bLength is zero or<br /> extends past the remaining endpoint-extra scan.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix a buffer leak in __ceph_setxattr()<br /> <br /> The old_blob in __ceph_setxattr() can store<br /> ci-&gt;i_xattrs.prealloc_blob value during the retry.<br /> However, it is never called the ceph_buffer_put()<br /> for the old_blob object. This patch fixes the issue of<br /> the buffer leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size<br /> <br /> The generic/642 test-case can reproduce the kernel crash:<br /> <br /> [40243.605254] ------------[ cut here ]------------<br /> [40243.605956] kernel BUG at fs/ceph/xattr.c:918!<br /> [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI<br /> [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)<br /> [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [40243.611820] Workqueue: ceph-msgr ceph_con_workfn<br /> [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0<br /> [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc<br /> [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287<br /> [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000<br /> [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000<br /> [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000<br /> [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000<br /> [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd<br /> [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000<br /> [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0<br /> [40243.627408] Call Trace:<br /> [40243.627839] <br /> [40243.628188] __prep_cap+0x3fd/0x4a0<br /> [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0<br /> [40243.629474] ceph_check_caps+0x46a/0xc80<br /> [40243.630094] ? __lock_acquire+0x4a2/0x2650<br /> [40243.630773] ? find_held_lock+0x31/0x90<br /> [40243.631347] ? handle_cap_grant+0x79f/0x1060<br /> [40243.632068] ? lock_release+0xd9/0x300<br /> [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340<br /> [40243.633429] ? lock_release+0xd9/0x300<br /> [40243.634052] handle_cap_grant+0xcf6/0x1060<br /> [40243.634745] ceph_handle_caps+0x122b/0x2110<br /> [40243.635415] mds_dispatch+0x5bd/0x2160<br /> [40243.636034] ? ceph_con_process_message+0x65/0x190<br /> [40243.636828] ? lock_release+0xd9/0x300<br /> [40243.637431] ceph_con_process_message+0x7a/0x190<br /> [40243.638184] ? kfree+0x311/0x4f0<br /> [40243.638749] ? kfree+0x311/0x4f0<br /> [40243.639268] process_message+0x16/0x1a0<br /> [40243.639915] ? sg_free_table+0x39/0x90<br /> [40243.640572] ceph_con_v2_try_read+0xf58/0x2120<br /> [40243.641255] ? lock_acquire+0xc8/0x300<br /> [40243.641863] ceph_con_workfn+0x151/0x820<br /> [40243.642493] process_one_work+0x22f/0x630<br /> [40243.643093] ? process_one_work+0x254/0x630<br /> [40243.643770] worker_thread+0x1e2/0x400<br /> [40243.644332] ? __pfx_worker_thread+0x10/0x10<br /> [40243.645020] kthread+0x109/0x140<br /> [40243.645560] ? __pfx_kthread+0x10/0x10<br /> [40243.646125] ret_from_fork+0x3f8/0x480<br /> [40243.646752] ? __pfx_kthread+0x10/0x10<br /> [40243.647316] ? __pfx_kthread+0x10/0x10<br /> [40243.647919] ret_from_fork_asm+0x1a/0x30<br /> [40243.648556] <br /> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore<br /> [40243.654766] ---[ end trace 0000000000000000 ]---<br /> <br /> Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS<br /> maximum xattr size") moved the required_blob_size computation to before<br /> the __build_xattrs() call, introducing a race.<br /> <br /> __build_xattrs() releases and reacquires i_ceph_lock during execution.<br /> In that window, handle_cap_grant() may update i_xattrs.blob with a<br /> newer MDS-provided blob and bump i_xattrs.version. When<br /> __bui<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: put folios not suitable for writeback<br /> <br /> The batch holds references to the folios (see `filemap_get_folios`,<br /> `folio_batch_release`), so we need to `folio_put` the folios we remove.<br /> <br /> Tested on v6.18.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt: sev-guest: Do not use host-controlled page order in cleanup path<br /> <br /> When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),<br /> get_ext_report() allocates a buffer to retrieve a certificate blob from the<br /> host, keeping track of its size in report_req-&gt;certs_len.<br /> <br /> However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating<br /> an invalid buffer size, as well as the expected length of such buffer.<br /> get_ext_report() subsequently updates report_req-&gt;certs_len with the<br /> host-controlled value, and cleans up the buffer by computing a page order<br /> from such value. This is incorrect, as the host-provided length may not<br /> match the page order of the original allocation, potentially resulting<br /> in corruption in the page allocator.<br /> <br /> Fix this by using alloc_pages_exact() instead, and reusing @npages to<br /> compute the size passed to free_pages_exact(). For consistency, also<br /> use @npages to compute the size when allocating the pages, even though<br /> this last change has no functional effect.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential out-of-bounds access in osdmap_decode()<br /> <br /> When decoding osd_state and osd_weight from an incoming osdmap in<br /> osdmap_decode(), both are decoded for each osd, i.e., map-&gt;max_osd<br /> times. The ceph_decode_need() check only accounts for<br /> sizeof(*map-&gt;osd_weight) once. This can potentially result in an<br /> out-of-bounds memory access if the incoming message is corrupted such<br /> that the max_osd value exceeds the actual content of the osdmap message.<br /> <br /> This patch fixes the issue by changing the corresponding part in the<br /> ceph_decode_need() check to account for<br /> map-&gt;max_osd*sizeof(*map-&gt;osd_weight).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure<br /> <br /> When ttm_tt_swapout() fails, the current code calls<br /> ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail()<br /> to restore the resource&amp;#39;s bulk_move membership.<br /> <br /> However, ttm_resource_move_to_lru_tail() places the resource at the tail<br /> of the LRU list which, relative to the walk cursor&amp;#39;s hitch node (placed<br /> immediately after the resource when it was yielded), puts the resource<br /> *in front of the* the hitch. The next list_for_each_entry_continue() from<br /> the hitch finds the same resource again, causing an infinite loop.<br /> <br /> Fix by deferring del_bulk_move to the success path only.<br /> <br /> On the success path, TTM_TT_FLAG_SWAPPED has just been set by<br /> ttm_tt_swapout() but the resource is still tracked in the bulk_move range,<br /> so ttm_resource_del_bulk_move()&amp;#39;s !ttm_resource_unevictable() guard would<br /> incorrectly skip the removal. Introduce<br /> ttm_resource_del_bulk_move_unevictable() which bypasses that guard.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/dma-buf: handle empty bo and UAF races<br /> <br /> There look to be some nasty races here when triggering the<br /> invalidate_mappings hook:<br /> <br /> 1) We do xe_bo_alloc() followed by the attach, before the actual full bo<br /> init step in xe_dma_buf_init_obj(). However the bo is visible on the<br /> attachments list after the attach. This is bad since exporter driver,<br /> say amdgpu, can at any time call back into our invalidate_mappings hook,<br /> with an empty/bogus bo, leading to potential bugs/crashes.<br /> <br /> 2) Similar to 1) but here we get a UAF, when the invalidate_mappings<br /> hook is triggered. For example, we get as far as xe_bo_init_locked()<br /> but this fails in some way. But here the bo will be freed on error, but<br /> we still have it attached from dma-buf pov, so if the<br /> invalidate_mappings is now triggered then the bo we access is gone and<br /> we trigger UAF and more bugs/crashes.<br /> <br /> To fix this, move the attach step until after we actually have a fully<br /> set up buffer object. Note that the bo is not published to userspace<br /> until later, so not sure what the comment "Don&amp;#39;t publish the bo<br /> until we have a valid attachment", is referring to.<br /> <br /> We have at least two different customers reporting hitting a NULL ptr<br /> deref in evict_flags when importing something from amdgpu, followed by<br /> triggering the evict flow. Hit rate is also pretty low, which would<br /> hint at some kind of race, so something like 1) or 2) might explain<br /> this.<br /> <br /> v2:<br /> - Shuffle the order of the ops slightly (no functional change)<br /> - Improve the comment to better explain the ordering (Matt B)<br /> <br /> (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset<br /> <br /> In __iommu_group_set_domain_internal(), concurrent domain attachments are<br /> rejected when any device in the group is recovering. This is necessary to<br /> fence concurrent attachments to a multi-device group where devices might<br /> share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in<br /> __iommu_group_set_domain_nofail().<br /> <br /> Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such<br /> as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should<br /> not be rejected, as the domain would be freed anyway in these nofail paths<br /> while group-&gt;domain is still pointing to it. So pci_dev_reset_iommu_done()<br /> could trigger a UAF when re-attaching group-&gt;domain.<br /> <br /> Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through<br /> the group-&gt;recovery_cnt fence, so as to update the group-&gt;domain pointer.<br /> Instead add a gdev-&gt;blocked check in the device iteration loop, to prevent<br /> any concurrent per-device detachment.