Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix misalignment bug in struct virtnet_info<br /> <br /> Use the new TRAILING_OVERLAP() helper to fix a misalignment bug<br /> along with the following warning:<br /> <br /> drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]<br /> <br /> This helper creates a union between a flexible-array member (FAM)<br /> and a set of members that would otherwise follow it (in this case<br /> `u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This<br /> overlays the trailing members (rss_hash_key_data) onto the FAM<br /> (hash_key_data) while keeping the FAM and the start of MEMBERS aligned.<br /> The static_assert() ensures this alignment remains.<br /> <br /> Notice that due to tail padding in flexible `struct<br /> virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`<br /> (at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at<br /> offset 84 in struct virtnet_info) are misaligned by one byte. See<br /> below:<br /> <br /> struct virtio_net_rss_config_trailer {<br /> __le16 max_tx_vq; /* 0 2 */<br /> __u8 hash_key_length; /* 2 1 */<br /> __u8 hash_key_data[]; /* 3 0 */<br /> <br /> /* size: 4, cachelines: 1, members: 3 */<br /> /* padding: 1 */<br /> /* last cacheline: 4 bytes */<br /> };<br /> <br /> struct virtnet_info {<br /> ...<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */<br /> <br /> /* XXX last struct has 1 byte of padding */<br /> <br /> u8 rss_hash_key_data[40]; /* 84 40 */<br /> ...<br /> /* size: 832, cachelines: 13, members: 48 */<br /> /* sum members: 801, holes: 8, sum holes: 31 */<br /> /* paddings: 2, sum paddings: 5 */<br /> };<br /> <br /> After changes, those members are correctly aligned at offset 795:<br /> <br /> struct virtnet_info {<br /> ...<br /> union {<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */<br /> struct {<br /> unsigned char __offset_to_hash_key_data[3]; /* 792 3 */<br /> u8 rss_hash_key_data[40]; /* 795 40 */<br /> }; /* 792 43 */<br /> }; /* 792 44 */<br /> ...<br /> /* size: 840, cachelines: 14, members: 47 */<br /> /* sum members: 801, holes: 8, sum holes: 35 */<br /> /* padding: 4 */<br /> /* paddings: 1, sum paddings: 4 */<br /> /* last cacheline: 8 bytes */<br /> };<br /> <br /> As a result, the RSS key passed to the device is shifted by 1<br /> byte: the last byte is cut off, and instead a (possibly<br /> uninitialized) byte is added at the beginning.<br /> <br /> As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also<br /> moved to the end, since it seems those three members should stick<br /> around together. :)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure<br /> <br /> When a context DAMON sysfs directory setup is failed after setup of attrs/<br /> directory, subdirectories of attrs/ directory are not cleaned up. As a<br /> result, DAMON sysfs interface is nearly broken until the system reboots,<br /> and the memory for the unremoved directory is leaked.<br /> <br /> Cleanup the directories under such failures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref<br /> <br /> The error branch for ext4_xattr_inode_update_ref forget to release the<br /> refcount for iloc.bh. Find this when review code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work<br /> <br /> hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling<br /> hci_uart_register_dev(), which calls proto-&gt;open() to initialize<br /> hu-&gt;priv. However, if a TTY write wakeup occurs during this window,<br /> hci_uart_tx_wakeup() may schedule write_work before hu-&gt;priv is<br /> initialized, leading to a NULL pointer dereference in<br /> hci_uart_write_work() when proto-&gt;dequeue() accesses hu-&gt;priv.<br /> <br /> The race condition is:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> hci_uart_set_proto()<br /> set_bit(HCI_UART_PROTO_INIT)<br /> hci_uart_register_dev()<br /> tty write wakeup<br /> hci_uart_tty_wakeup()<br /> hci_uart_tx_wakeup()<br /> schedule_work(&amp;hu-&gt;write_work)<br /> proto-&gt;open(hu)<br /> // initializes hu-&gt;priv<br /> hci_uart_write_work()<br /> hci_uart_dequeue()<br /> proto-&gt;dequeue(hu)<br /> // accesses hu-&gt;priv (NULL!)<br /> <br /> Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto-&gt;open()<br /> succeeds, ensuring hu-&gt;priv is initialized before any work can be<br /> scheduled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix the folio leak on S390 hardware acceleration<br /> <br /> [BUG]<br /> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration<br /> buffer preparation"), we no longer release the folio of the page cache<br /> of folio returned by btrfs_compress_filemap_get_folio() for S390<br /> hardware acceleration path.<br /> <br /> [CAUSE]<br /> Before that commit, we call kumap_local() and folio_put() after handling<br /> each folio.<br /> <br /> Although the timing is not ideal (it release previous folio at the<br /> beginning of the loop, and rely on some extra cleanup out of the loop),<br /> it at least handles the folio release correctly.<br /> <br /> Meanwhile the refactored code is easier to read, it lacks the call to<br /> release the filemap folio.<br /> <br /> [FIX]<br /> Add the missing folio_put() for copy_data_into_buffer().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference<br /> <br /> There is a race condition in nvmet_bio_done() that can cause a NULL<br /> pointer dereference in blk_cgroup_bio_start():<br /> <br /> 1. nvmet_bio_done() is called when a bio completes<br /> 2. nvmet_req_complete() is called, which invokes req-&gt;ops-&gt;queue_response(req)<br /> 3. The queue_response callback can re-queue and re-submit the same request<br /> 4. The re-submission reuses the same inline_bio from nvmet_req<br /> 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)<br /> invokes bio_uninit() for inline_bio, which sets bio-&gt;bi_blkg to NULL<br /> 6. The re-submitted bio enters submit_bio_noacct_nocheck()<br /> 7. blk_cgroup_bio_start() dereferences bio-&gt;bi_blkg, causing a crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:blk_cgroup_bio_start+0x10/0xd0<br /> Call Trace:<br /> submit_bio_noacct_nocheck+0x44/0x250<br /> nvmet_bdev_execute_rw+0x254/0x370 [nvmet]<br /> process_one_work+0x193/0x3c0<br /> worker_thread+0x281/0x3a0<br /> <br /> Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()<br /> BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before<br /> the request can be re-submitted, preventing the race condition.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind<br /> <br /> Fix several issues in dw_dp_bind() error handling:<br /> <br /> 1. Missing return after drm_bridge_attach() failure - the function<br /> continued execution instead of returning an error.<br /> <br /> 2. Resource leak: drm_dp_aux_register() is not a devm function, so<br /> drm_dp_aux_unregister() must be called on all error paths after<br /> aux registration succeeds. This affects errors from:<br /> - drm_bridge_attach()<br /> - phy_init()<br /> - devm_add_action_or_reset()<br /> - platform_get_irq()<br /> - devm_request_threaded_irq()<br /> <br /> 3. Bug fix: platform_get_irq() returns the IRQ number or a negative<br /> error code, but the error path was returning ERR_PTR(ret) instead<br /> of ERR_PTR(dp-&gt;irq).<br /> <br /> Use a goto label for cleanup to ensure consistent error handling.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: fix dma_free_coherent() pointer<br /> <br /> dma_alloc_coherent() allocates a DMA mapped buffer and stores the<br /> addresses in XXX_unaligned fields. Those should be reused when freeing<br /> the buffer rather than the aligned addresses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: fix kmalloc_nolock() context check for PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current<br /> check in kmalloc_nolock() only verifies we&amp;#39;re not in NMI or hard IRQ<br /> context, but misses the case where preemption is disabled.<br /> <br /> When a BPF program runs from a tracepoint with preemption disabled<br /> (preempt_count &gt; 0), kmalloc_nolock() proceeds to call<br /> local_lock_irqsave() which attempts to acquire a sleeping lock,<br /> triggering:<br /> <br /> BUG: sleeping function called from invalid context<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128<br /> preempt_count: 2, expected: 0<br /> <br /> Fix this by checking !preemptible() on PREEMPT_RT, which directly<br /> expresses the constraint that we cannot take a sleeping lock when<br /> preemption is disabled. This encompasses the previous checks for NMI<br /> and hard IRQ contexts while also catching cases where preemption is<br /> disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dma_free_coherent() pointer<br /> <br /> dma_alloc_coherent() allocates a DMA mapped buffer and stores the<br /> addresses in XXX_unaligned fields. Those should be reused when freeing<br /> the buffer rather than the aligned addresses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: reset sparse-read state in osd_fault()<br /> <br /> When a fault occurs, the connection is abandoned, reestablished, and any<br /> pending operations are retried. The OSD client tracks the progress of a<br /> sparse-read reply using a separate state machine, largely independent of<br /> the messenger&amp;#39;s state.<br /> <br /> If a connection is lost mid-payload or the sparse-read state machine<br /> returns an error, the sparse-read state is not reset. The OSD client<br /> will then interpret the beginning of a new reply as the continuation of<br /> the old one. If this makes the sparse-read machinery enter a failure<br /> state, it may never recover, producing loops like:<br /> <br /> libceph: [0] got 0 extents<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> <br /> Therefore, reset the sparse-read state in osd_fault(), ensuring retries<br /> start from a clean state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: Fix memory leak in unittest_data_add()<br /> <br /> In unittest_data_add(), if of_resolve_phandles() fails, the allocated<br /> unittest_data is not freed, leading to a memory leak.<br /> <br /> Fix this by using scope-based cleanup helper __free(kfree) for automatic<br /> resource cleanup. This ensures unittest_data is automatically freed when<br /> it goes out of scope in error paths.<br /> <br /> For the success path, use retain_and_null_ptr() to transfer ownership<br /> of the memory to the device tree and prevent double freeing.