Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: validate payload size before accessing journal metadata<br /> <br /> r5c_recovery_analyze_meta_block() and<br /> r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a<br /> journal metadata block using on-disk payload size fields without<br /> validating them against the remaining space in the metadata block.<br /> <br /> A corrupted journal contains payload sizes extending beyond the PAGE_SIZE<br /> boundary can cause out-of-bounds reads when accessing payload fields or<br /> computing offsets.<br /> <br /> Add bounds validation for each payload type to ensure the full payload<br /> fits within meta_size before processing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()<br /> <br /> The mwifiex_adapter_cleanup() function uses timer_delete()<br /> (non-synchronous) for the wakeup_timer before the adapter structure is<br /> freed. This is incorrect because timer_delete() does not wait for any<br /> running timer callback to complete.<br /> <br /> If the wakeup_timer callback (wakeup_timer_fn) is executing when<br /> mwifiex_adapter_cleanup() is called, the callback will continue to<br /> access adapter fields (adapter-&gt;hw_status, adapter-&gt;if_ops.card_reset,<br /> etc.) which may be freed by mwifiex_free_adapter() called later in the<br /> mwifiex_remove_card() path.<br /> <br /> Use timer_delete_sync() instead to ensure any running timer callback has<br /> completed before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx<br /> <br /> The bounce buffers are allocated with __get_free_pages() using<br /> BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error<br /> path and nx842_crypto_free_ctx() release the buffers with free_page().<br /> Use free_pages() with the matching order instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: validate damos_quota_goal-&gt;nid for node_memcg_{used,free}_bp<br /> <br /> Users can set damos_quota_goal-&gt;nid with arbitrary value for<br /> node_memcg_{used,free}_bp. But DAMON core is using those for NODE-DATA()<br /> without a validation of the value. This can result in out of bounds<br /> memory access. The issue can actually triggered using DAMON user-space<br /> tool (damo), like below.<br /> <br /> $ sudo mkdir /sys/fs/cgroup/foo<br /> $ sudo ./damo start --damos_action stat --damos_quota_interval 1s \<br /> --damos_quota_goal node_memcg_used_bp 50% -1 /foo<br /> $ sudo dmseg<br /> [...]<br /> [ 524.181426] Unable to handle kernel paging request at virtual address 0000000000002c00<br /> <br /> Fix this issue by adding the validation of the given node id. If an<br /> invalid node id is given, it returns 0% for used memory ratio, and 100%<br /> for free memory ratio.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix num_ops off-by-one when crypto allocation fails<br /> <br /> move_dirty_folio_in_page_array() may fail if the file is encrypted, the<br /> dirty folio is not the first in the batch, and it fails to allocate a<br /> bounce buffer to hold the ciphertext. When that happens,<br /> ceph_process_folio_batch() simply redirties the folio and flushes the<br /> current batch -- it can retry that folio in a future batch.<br /> <br /> However, if this failed folio is not contiguous with the last folio that<br /> did make it into the batch, then ceph_process_folio_batch() has already<br /> incremented `ceph_wbc-&gt;num_ops`; because it doesn&amp;#39;t follow through and<br /> add the discontiguous folio to the array, ceph_submit_write() -- which<br /> expects that `ceph_wbc-&gt;num_ops` accurately reflects the number of<br /> contiguous ranges (and therefore the required number of "write extent"<br /> ops) in the writeback -- will panic the kernel:<br /> <br /> BUG_ON(ceph_wbc-&gt;op_idx + 1 != req-&gt;r_num_ops);<br /> <br /> This issue can be reproduced on affected kernels by writing to<br /> fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat<br /> pattern (total filesize should not matter) and gradually increasing the<br /> system&amp;#39;s memory pressure until a bounce buffer allocation fails.<br /> <br /> Fix this crash by decrementing `ceph_wbc-&gt;num_ops` back to the correct<br /> value when move_dirty_folio_in_page_array() fails, but the folio already<br /> started counting a new (i.e. still-empty) extent.<br /> <br /> The defect corrected by this patch has existed since 2022 (see first<br /> `Fixes:`), but another bug blocked multi-folio encrypted writeback until<br /> recently (see second `Fixes:`). The second commit made it into 6.18.16,<br /> 6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch<br /> therefore fixes a regression (panic) introduced by cac190c7674f.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info<br /> <br /> Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an<br /> instance as part of initializing deferred I/O and remove it only after<br /> the final mapping has been closed. If the fb_info and the contained<br /> deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info<br /> to invalidate the mapping. Any access will then result in a SIGBUS<br /> signal.<br /> <br /> Fixes a long-standing problem, where a device hot-unplug happens while<br /> user space still has an active mapping of the graphics memory. The hot-<br /> unplug frees the instance of struct fb_info. Accessing the memory will<br /> operate on undefined state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix integer overflow in run_unpack() volume boundary check<br /> <br /> The volume boundary check `lcn + len &gt; sbi-&gt;used.bitmap.nbits` uses raw<br /> addition which can wrap around for large lcn and len values, bypassing<br /> the validation. Use check_add_overflow() as is already done for the<br /> adjacent prev_lcn + dlcn and vcn64 + len checks added by commit<br /> 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()").<br /> <br /> Found by fuzzing with a source-patched harness (LibAFL + QEMU).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/shstk: Prevent deadlock during shstk sigreturn<br /> <br /> During sigreturn the shadow stack signal frame is popped. The kernel does<br /> this by reading the shadow stack using normal read accesses. When it can&amp;#39;t<br /> assume the memory is shadow stack, it takes extra steps to makes sure it is<br /> reading actual shadow stack memory and not other normal readable memory. It<br /> does this by holding the mmap read lock while doing the access and checking<br /> the flags of the VMA.<br /> <br /> Unfortunately that is not safe. If the read of the shadow stack sigframe<br /> hits a page fault, the fault handler will try to recursively grab another<br /> mmap read lock. This normally works ok, but if a writer on another CPU is<br /> also waiting, the second read lock could fail and cause a deadlock.<br /> <br /> Fix this by not holding mmap lock during the read access to userspace.<br /> <br /> Instead use mmap_lock_speculate_...() to watch for changes between dropping<br /> mmap lock and the userspace access. Retry if anything grabbed an mmap write<br /> lock in between and could have changed the VMA.<br /> <br /> These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only<br /> available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK<br /> depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP<br /> kernels. So drop support for the other configs under the assumption that<br /> the !SMP shadow stack user base does not exist.<br /> <br /> Currently there is a check that skips the lookup work when the SSP can be<br /> assumed to be on a shadow stack. While reorganizing the function, remove<br /> the optimization to make the tricky code flows more common, such that<br /> issues like this cannot escape detection for so long.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmasm: fix heap over-read in ibmasm_send_i2o_message()<br /> <br /> The ibmasm_send_i2o_message() function uses get_dot_command_size() to<br /> compute the byte count for memcpy_toio(), but this value is derived from<br /> user-controlled fields in the dot_command_header (command_size: u8,<br /> data_size: u16) and is never validated against the actual allocation size.<br /> A root user can write a small buffer with inflated header fields, causing<br /> memcpy_toio() to read up to ~65 KB past the end of the allocation into<br /> adjacent kernel heap, which is then forwarded to the service processor<br /> over MMIO.<br /> <br /> Silently clamping the copy size is not sufficient: if the header fields<br /> claim a larger size than the buffer, the SP receives a dot command whose<br /> own header is inconsistent with the I2O message length, which can cause<br /> the SP to desynchronize. Reject such commands outright by returning<br /> failure.<br /> <br /> Validate command_size before calling get_mfa_inbound() to avoid leaking<br /> an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware<br /> frame from the controller&amp;#39;s free pool, and returning without a<br /> corresponding set_mfa_inbound() call would permanently exhaust it.<br /> <br /> Additionally, clamp command_size to I2O_COMMAND_SIZE before the<br /> memcpy_toio() so the MMIO write stays within the I2O message frame,<br /> consistent with the clamping already performed by outgoing_message_size()<br /> for the header field.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Always use NextRIP as vmcb02&amp;#39;s NextRIP after first L2 VMRUN<br /> <br /> For guests with NRIPS disabled, L1 does not provide NextRIP when running<br /> an L2 with an injected soft interrupt, instead it advances the current RIP<br /> before running it. KVM uses the current RIP as the NextRIP in vmcb02 to<br /> emulate a CPU without NRIPS.<br /> <br /> However, after L2 runs the first time, NextRIP will be updated by the CPU<br /> and/or KVM, and the current RIP is no longer the correct value to use in<br /> vmcb02. Hence, after save/restore, use the current RIP if and only if a<br /> nested run is pending, otherwise use NextRIP. Give soft_int_next_rip the<br /> same treatment, as it&amp;#39;s the same logic, just for a narrower use case.<br /> <br /> [sean: give soft_int_next_rip the same treatment]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix IRQ cleanup on 6xxx probe failure<br /> <br /> When adf_dev_up() partially completes and then fails, the IRQ<br /> handlers registered during adf_isr_resource_alloc() are not detached<br /> before the MSI-X vectors are released.<br /> <br /> Since the device is enabled with pcim_enable_device(), calling<br /> pci_alloc_irq_vectors() internally registers pcim_msi_release() as a<br /> devres action. On probe failure, devres runs pcim_msi_release() which<br /> calls pci_free_irq_vectors(), tearing down the MSI-X vectors while IRQ<br /> handlers (for example &amp;#39;qat0-bundle0&amp;#39;) are still attached. This causes<br /> remove_proc_entry() warnings:<br /> <br /> [ 22.163964] remove_proc_entry: removing non-empty directory &amp;#39;irq/143&amp;#39;, leaking at least &amp;#39;qat0-bundle0&amp;#39;<br /> <br /> Moving the devm_add_action_or_reset() before adf_dev_up() does not solve<br /> the problem since devres runs in LIFO order and pcim_msi_release(),<br /> registered later inside adf_dev_up(), would still fire before<br /> adf_device_down().<br /> <br /> Fix by calling adf_dev_down() explicitly when adf_dev_up() fails, to<br /> properly free IRQ handlers before devres releases the MSI-X vectors.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix deadlock in jbd2_journal_cancel_revoke()<br /> <br /> Commit f76d4c28a46a ("fs/jbd2: use sleeping version of<br /> __find_get_block()") changed jbd2_journal_cancel_revoke() to use<br /> __find_get_block_nonatomic() which holds the folio lock instead of<br /> i_private_lock. This breaks the lock ordering (folio -&gt; buffer) and<br /> causes an ABBA deadlock when the filesystem blocksize