Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix resource leak on mmiotrace trace_pipe close<br /> <br /> The mmiotrace tracer was added May 12th 2008. At that time, resources<br /> created in pipe_open() could not be freed because there was not<br /> pipe_close function pointer of the tracer. The pipe_close function pointer<br /> was added in December 7th, 2009, but the mmiotrace tracer was not updated.<br /> <br /> mmio_pipe_open() allocates a header_iter and takes a pci_dev reference<br /> when trace_pipe is opened. mmio_close() frees them, but it was only<br /> wired to the tracer&amp;#39;s .close callback.<br /> <br /> tracing_release_pipe() invokes .pipe_close, not .close, when the<br /> trace_pipe file is released. As a result, closing trace_pipe with the<br /> mmiotrace tracer active leaked the header_iter allocation and left a<br /> stale pci_dev reference.<br /> <br /> Set .pipe_close to mmio_close, matching how function_graph wires both<br /> callbacks to the same handler.<br /> <br /> Note, if the trace_pipe is read to completion, it will clean up the<br /> resources, but if one were to run:<br /> <br /> # head -n 1 /sys/kernel/tracing/trace_pipe<br /> VERSION 20070824<br /> <br /> Over and over again, it would trigger a massive leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix mmiotrace possible NULL dereferencing of hiter-&gt;dev<br /> <br /> If the mmio_pipe_open() fails to find a PCI device, the hiter-&gt;dev<br /> will be assigned to NULL. The mmiotrace read() function dereferences the<br /> hiter-&gt;dev if hiter exists.<br /> <br /> Change the test of the read to not only check hiter being NULL, but also<br /> the hiter-&gt;dev before dereferencing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: fix MSC output device reference leak<br /> <br /> intel_th_output_open() looks up the output device with<br /> bus_find_device_by_devt(), which returns the device with a reference that<br /> must be dropped after use.<br /> <br /> commit 95fc36a234da ("intel_th: fix device leak on output open()")<br /> attempted to drop the reference from intel_th_output_release(). However,<br /> a successful open replaces file-&gt;f_op with the output driver file<br /> operations before returning, so close runs the output driver release<br /> callback instead.<br /> <br /> For MSC outputs, close runs intel_th_msc_release(), which only removes<br /> the per-file iterator and does not drop the device reference taken by<br /> intel_th_output_open(). Consequently, every successful MSC output open<br /> leaks one device reference.<br /> <br /> Drop the device reference from intel_th_msc_release(), which is the<br /> release path actually used for MSC output files. Remove the now-unused<br /> intel_th_output_release() callback from intel_th_output_fops.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: prevent registration of special VMAs<br /> <br /> Vova Tokarev says:<br /> <br /> userfaultfd allows registration on shadow stack VMAs. With userfaultfd<br /> access, you can register on the shadow stack, discard a page ... and<br /> inject a page with chosen return addresses via UFFDIO_COPY.<br /> <br /> Update vma_can_userfault() to reject VM_SHADOW_STACK.<br /> <br /> While on it, also reject VM_SPECIAL so that if a driver would implement<br /> vm_uffd_ops, it wouldn&amp;#39;t be possible to register special VMAs with<br /> userfaultfd.<br /> <br /> Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude<br /> hugetlb VMAs from the check for VM_SPECIAL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not try compression for data reloc inodes<br /> <br /> [BUG]<br /> There is a syzbot report that the check inside get_new_location()<br /> triggered:<br /> <br /> BTRFS info (device loop0): found 31 extents, stage: move data extents<br /> BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607<br /> item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160<br /> inode generation 5 transid 0 size 0 nbytes 0<br /> block group 0 mode 40755 links 1 uid 0 gid 0<br /> rdev 0 sequence 0 flags 0x0<br /> atime 1669132761.0<br /> ctime 1669132761.0<br /> mtime 1669132761.0<br /> otime 0.0<br /> item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12<br /> index 0 name_len 2<br /> item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160<br /> inode generation 1 transid 16 size 733184 nbytes 106496<br /> block group 0 mode 100600 links 0 uid 0 gid 0<br /> rdev 0 sequence 24 flags 0x18<br /> item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68<br /> generation 16 type 0<br /> inline extent data size 47 ram_bytes 4096 compression 1<br /> [...]<br /> item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0<br /> BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337<br /> ------------[ cut here ]------------<br /> btrfs_abort_should_print_stack(__error)<br /> <br /> [CAUSE]<br /> The above dump tree shows the first file extent item is inlined, which<br /> should make no sense for data reloc inodes, as such inodes just<br /> represent where the data extents are in the relocation destination chunk.<br /> <br /> However the relocation path preallocates space for each block,<br /> then dirties them, cluster by cluster.<br /> It&amp;#39;s possible to have a single block at the beginning of the block<br /> group, and no other block in the same cluster.<br /> <br /> So relocation will preallocate a file extent for that block and dirty<br /> the first block. Then memory pressure forces the data reloc inode to be<br /> written back, before any other blocks are dirtied/allocated.<br /> <br /> Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated<br /> delalloc helper") changed the sequence of delalloc. Before that commit we<br /> always tried NOCOW first, so that dirtied block would be written back into<br /> the preallocated space, and appear as a regular extent.<br /> <br /> But with that commit, we always try inline first, and since compression<br /> is forced, we try compressing the first block, and then inline the<br /> compressed data, resulting in the above inlined file extent in the data<br /> reloc tree.<br /> <br /> Then the check in get_new_location() will check the file offset, without<br /> checking if the file extent is inlined or not, resulting in the above<br /> failure.<br /> <br /> [FIX]<br /> Do not allow compression for data reloc inodes.<br /> <br /> Since data reloc inode sizes are always block aligned, as long as we do<br /> not compress, @data_len will always be at least one block, and<br /> that will cause can_cow_file_range_inline() to return false, thus no<br /> inlined extent will be created.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix afs_edit_dir_remove() to get, not find, block 0<br /> <br /> Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather<br /> than afs_dir_find_block() as the latter caches the found block in the<br /> afs_dir_iter and may[*] switch out the page it&amp;#39;s on if another<br /> afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does.<br /> <br /> [*] There&amp;#39;s more than one block per page.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: userspace: fix use-after-free in get_local_id<br /> <br /> In mptcp_pm_userspace_get_local_id(), the address entry is looked up under<br /> spinlock, but its id is read after dropping the lock. A concurrent deletion<br /> can free the entry between the unlock and the read, leading to UAF.<br /> <br /> The race window is narrow. It was reproduced only with a locally<br /> constructed stress test that repeatedly overlaps an MP_JOIN SYN with a<br /> MPTCP_PM_CMD_SUBFLOW_DESTROY request.<br /> <br /> However, the KASAN report below confirms that the race is reachable:<br /> <br /> [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0<br /> [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0<br /> ...<br /> [ 666.319401] Call Trace:<br /> [ 666.319405] <br /> [ 666.319408] dump_stack_lvl+0x53/0x70<br /> [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0<br /> [ 666.319418] print_report+0xbe/0x2b0<br /> [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0<br /> [ 666.319423] kasan_report+0xce/0x100<br /> [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0<br /> [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0<br /> [ 666.319433] mptcp_pm_get_local_id+0x371/0x440<br /> ...<br /> [ 666.319821] Allocated by task 45539:<br /> [ 666.319844] kasan_save_stack+0x33/0x60<br /> [ 666.319855] kasan_save_track+0x14/0x30<br /> [ 666.319858] __kasan_kmalloc+0x8f/0xa0<br /> [ 666.319863] __kmalloc_noprof+0x1e7/0x520<br /> [ 666.319867] sock_kmalloc+0xdf/0x130<br /> [ 666.319885] sock_kmemdup+0x1b/0x40<br /> [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500<br /> [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610<br /> ...<br /> [ 666.319967] Freed by task 45560:<br /> [ 666.319988] kasan_save_stack+0x33/0x60<br /> [ 666.319991] kasan_save_track+0x14/0x30<br /> [ 666.319994] kasan_save_free_info+0x3b/0x60<br /> [ 666.319998] __kasan_slab_free+0x43/0x70<br /> [ 666.320000] kfree+0x166/0x440<br /> [ 666.320003] sock_kfree_s+0x1d/0x50<br /> [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200<br /> [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0<br /> <br /> Fix by copying the id into a local variable while still holding the lock,<br /> and use -1 as a "not found" sentinel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix stale skb-&gt;sk reference on subflow close<br /> <br /> The backlog list is updated by mptcp_data_ready() under<br /> mptcp_data_lock(). The cleanup of backlog references to a closing<br /> subflow, however, was performed in mptcp_close_ssk(), before<br /> __mptcp_close_ssk() acquires the ssk lock, and while holding neither<br /> the ssk lock nor mptcp_data_lock().<br /> <br /> Because that traversal ran without mptcp_data_lock(), concurrent softirq<br /> RX processing on another CPU (subflow_data_ready() -&gt; mptcp_data_ready()<br /> -&gt; __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog<br /> entry referencing the ssk while the cleanup loop was in progress. Such<br /> an entry could be missed by the cleanup, or the concurrent list update<br /> could corrupt the traversal, leaving skb-&gt;sk pointing at the ssk after<br /> it is freed.<br /> <br /> A later mptcp_backlog_purge() then dereferences the stale pointer,<br /> triggering a warning in inet_sock_destruct() (ssk-&gt;sk_rmem_alloc != 0)<br /> followed by a use-after-free in mptcp_backlog_purge().<br /> <br /> Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after<br /> subflow-&gt;closing is set to 1 and while the ssk lock is still held,<br /> serialized under mptcp_data_lock(). The cleanup runs only on the push<br /> path (MPTCP_CF_PUSH), where backlog references accumulate; on other<br /> teardown paths the caller already handles cleanup.<br /> <br /> With subflow-&gt;closing set and mptcp_data_lock() held across the purge,<br /> any concurrent mptcp_data_ready() either completes its enqueue before<br /> the purge runs and is caught, or observes closing=1 and bails out. Once<br /> mptcp_data_unlock() is reached, no new skb referencing the ssk can be<br /> enqueued, so the cleanup is exhaustive.<br /> <br /> Remove the unprotected traversal from mptcp_close_ssk() entirely.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: make huge_ptep_get handled unaligned addresses<br /> <br /> huge_ptep_get() can be handed a virtual address pointing to the middle<br /> of a contpmd/contpte mapped hugetlb folio (examples of callers are<br /> pagemap_hugetlb_range, page_mapped_in_vma).<br /> <br /> The arm64 helper rewalks the pgtables in find_num_contig to answer<br /> whether the huge pte we have maps a contpmd or a contpte hugetlb folio,<br /> and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over<br /> the contiguous ptes. We can falsely return CONT_PTES instead of<br /> CONT_PMDS if the addr is not aligned. On systems where CONT_PTES !=<br /> CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit<br /> state, meaning extra work for the kernel. Even worse, we may iterate<br /> beyond the PTE table and dereference a garbage ptep pointer to access<br /> physical memory we don&amp;#39;t own. Since the ptep pointer is a linear map<br /> address, we may run off the end of the linear map or into a hole,<br /> dereference a VA not mapped into the kernel pgtables and cause kernel<br /> panic.<br /> <br /> Fix this by aligning the pmdp pointer down to a contpmd base before<br /> checking equality with the passed huge pte pointer, to correctly answer<br /> whether the huge pte is the base of a contpmd block.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE<br /> <br /> __decode_pg_temp() decodes an user-controlled length but only rejects<br /> values large enough to overflow the allocation; it does not bound it to<br /> CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and<br /> apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size<br /> on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends<br /> an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack<br /> out-of-bounds write.<br /> <br /> An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer<br /> entries at decode time. The bound is well below the old overflow threshold, so<br /> it also covers the allocation-size overflow the previous check guarded against.<br /> <br /> BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds<br /> Write of size 4 ... by task exploit<br /> kasan_report (mm/kasan/report.c:595)<br /> ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833)<br /> calc_target (net/ceph/osd_client.c:1638)<br /> __submit_request (net/ceph/osd_client.c:2394)<br /> ceph_osdc_start_request (net/ceph/osd_client.c:2490)<br /> ceph_osdc_call (net/ceph/osd_client.c:5164)<br /> rbd_dev_image_probe (drivers/block/rbd.c:6899)<br /> do_rbd_add (drivers/block/rbd.c:7138)<br /> ...<br /> kernel BUG at net/ceph/osdmap.c:2670!<br /> <br /> [ idryomov: do the same in __decode_pg_upmap_items() ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: close UDP tunnel sockets during netns teardown<br /> <br /> proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when<br /> net.sctp.udp_port is set, and stops/restarts them when the sysctl value<br /> changes. The netns exit path does not stop these sockets, so a namespace<br /> can be torn down while its SCTP UDP tunnel sockets are still installed.<br /> <br /> Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering<br /> the per-net sysctl table. This prevents new sysctl writes from racing in<br /> while the sockets are being released, and closes the sockets before the<br /> control socket is destroyed.