Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: cbb: Fix cross-fabric target timeout lookup<br /> <br /> When a fabric receives an error interrupt, the error may have<br /> occurred on a different fabric. The target timeout lookup was using<br /> the wrong base address (cbb-&gt;regs) with offsets from a different<br /> fabric&amp;#39;s target map, causing a kernel page fault.<br /> <br /> Unable to handle kernel paging request at virtual address ffff80000954cc00<br /> pc : tegra234_cbb_get_tmo_slv+0xc/0x28<br /> Call trace:<br /> tegra234_cbb_get_tmo_slv+0xc/0x28<br /> print_err_notifier+0x6c0/0x7d0<br /> tegra234_cbb_isr+0xe4/0x1b4<br /> <br /> Add tegra234_cbb_get_fabric() to look up the correct fabric device<br /> using fab_id, and use its base address for accessing target timeout<br /> registers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix uninit-value in fuse_dentry_revalidate()<br /> <br /> fuse_dentry_revalidate() may be called with a dentry that didn&amp;#39;t had<br /> -&gt;d_time initialised. The issue was found with KMSAN, where lookup_open()<br /> calls __d_alloc(), followed by d_revalidate(), as shown below:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394<br /> fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394<br /> d_revalidate fs/namei.c:1030 [inline]<br /> lookup_open fs/namei.c:4405 [inline]<br /> open_last_lookups fs/namei.c:4583 [inline]<br /> path_openat+0x1614/0x64c0 fs/namei.c:4827<br /> do_file_open+0x2aa/0x680 fs/namei.c:4859<br /> [...]<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4466 [inline]<br /> slab_alloc_node mm/slub.c:4788 [inline]<br /> kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807<br /> __d_alloc+0x55/0xa00 fs/dcache.c:1740<br /> d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604<br /> lookup_open fs/namei.c:4398 [inline]<br /> open_last_lookups fs/namei.c:4583 [inline]<br /> path_openat+0x135f/0x64c0 fs/namei.c:4827<br /> do_file_open+0x2aa/0x680 fs/namei.c:4859<br /> [...]<br /> =====================================================

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: Remove overflows on the invalidation path<br /> <br /> Since RISC-V supports a sign extended page table it should support<br /> a gather-&gt;end of ULONG_MAX, but if this happens it will infinite loop<br /> because of the overflow.<br /> <br /> Also avoid overflow computing the length by moving the +1 to the other<br /> side of the

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths<br /> <br /> In dc_dmub_srv_log_diagnostic_data() and<br /> dc_dmub_srv_enable_dpia_trace().<br /> <br /> Both functions check:<br /> <br /> if (!dc_dmub_srv || !dc_dmub_srv-&gt;dmub)<br /> <br /> and then call DC_LOG_ERROR() inside that block.<br /> <br /> DC_LOG_ERROR() uses dc_dmub_srv-&gt;ctx internally. So if<br /> dc_dmub_srv is NULL, the logging itself can dereference a<br /> NULL pointer and cause a crash.<br /> <br /> Fix this by splitting the checks.<br /> <br /> First check if dc_dmub_srv is NULL and return immediately.<br /> Then check dc_dmub_srv-&gt;dmub and log the error only when<br /> dc_dmub_srv is valid.<br /> <br /> Fixes the below:<br /> ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed &amp;#39;dc_dmub_srv&amp;#39; could be null (see line 961)<br /> ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed &amp;#39;dc_dmub_srv&amp;#39; could be null (see line 1166)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: Put CPU offline callback in ONLINE section to allow failure<br /> <br /> syzbot reported the following warning:<br /> <br /> DEAD callback error for CPU1<br /> WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614<br /> <br /> at commit 4ae12d8bd9a8 ("Merge tag &amp;#39;kbuild-fixes-7.0-2&amp;#39; of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux")<br /> which tglx traced to padata_cpu_dead() given it&amp;#39;s the only<br /> sub-CPUHP_TEARDOWN_CPU callback that returns an error.<br /> <br /> Failure isn&amp;#39;t allowed in hotplug states before CPUHP_TEARDOWN_CPU<br /> so move the CPU offline callback to the ONLINE section where failure is<br /> possible.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp()<br /> <br /> ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp<br /> (in seconds since the Unix epoch) through a platform-specific RAS system<br /> callback and is used for timestamping RAS error events.<br /> <br /> The function checks ras_core in the conditional statement before calling<br /> the sys_fn callback. However, when the condition fails, the function<br /> prints an error message using ras_core-&gt;dev.<br /> <br /> If ras_core is NULL, this can lead to a potential NULL pointer<br /> dereference when accessing ras_core-&gt;dev.<br /> <br /> Add an early NULL check for ras_core at the beginning of the function<br /> and return 0 when the pointer is not valid. This prevents the<br /> dereference and makes the control flow clearer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected()<br /> <br /> Fixes a NULL pointer dereference when ras_core is NULL and ras_core-&gt;dev<br /> is accessed in the error path.<br /> <br /> Reported by: Dan Carpenter

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()<br /> <br /> If queue entry or DMA descriptor list allocation fails in<br /> airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a<br /> NULL pointer dereference running netif_napi_del() for RX queue NAPIs<br /> since netif_napi_add() has never been executed to this particular RX NAPI.<br /> The issue is due to the early ndesc initialization in<br /> airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc<br /> value to check if the queue is properly initialized. Fix the issue moving<br /> ndesc initialization at end of airoha_qdma_init_tx routine.<br /> Move page_pool allocation after descriptor list allocation in order to<br /> avoid memory leaks if desc allocation fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()<br /> <br /> If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,<br /> airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference<br /> accessing the queue entry array. The issue is due to the early ndesc<br /> initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc<br /> initialization at end of airoha_qdma_init_tx routine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: fix NTMP DMA use-after-free issue<br /> <br /> The AI-generated review reported a potential DMA use-after-free issue<br /> [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending<br /> command is not explicitly aborted, while ntmp_free_data_mem()<br /> unconditionally frees the DMA buffer. If the buffer has already been<br /> reallocated elsewhere, this may lead to silent memory corruption. Because<br /> the hardware eventually processes the pending command and perform a DMA<br /> write of the response to the physical address of the freed buffer.<br /> <br /> To resolve this issue, this patch does the following modifications:<br /> <br /> 1. Convert cbdr-&gt;ring_lock from a spinlock to a mutex<br /> <br /> The lock was originally a spinlock in case NTMP operations might be<br /> invoked from atomic context. After downstream support for all NTMP<br /> tables, no such usage has materialized. A mutex lock is now required<br /> because the driver now needs to reclaim used BDs and release associated<br /> DMA memory within the lock&amp;#39;s context, while dma_free_coherent() might<br /> sleep.<br /> <br /> 2. Introduce software command BD (struct netc_swcbd)<br /> <br /> The hardware write-back overwrites the addr and len fields of the BD,<br /> so the driver cannot rely on the hardware BD to free the associated DMA<br /> memory. The driver now maintains a software shadow BD storing the DMA<br /> buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only<br /> reclaims older BDs when the number of used BDs reaches<br /> NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory<br /> release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no<br /> longer needed and are removed.<br /> <br /> 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd()<br /> <br /> netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes<br /> consuming the response. At this point, if a concurrent thread submits<br /> a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer<br /> while it is still in use. Move ring_lock ownership to the caller to<br /> ensure the response buffer cannot be reclaimed prematurely. So the<br /> helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added.<br /> <br /> These changes eliminate the DMA use-after-free condition and ensure safe<br /> and consistent BD reclamation and DMA buffer lifecycle management.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reset: amlogic: t7: Fix null reset ops<br /> <br /> Fix missing reset ops causing kernel null pointer dereference.<br /> This SOC&amp;#39;s reset is currently not used yet.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: eip93 - fix hmac setkey algo selection<br /> <br /> eip93_hmac_setkey() allocates a temporary ahash transform for<br /> computing HMAC ipad/opad key material. The allocation uses the<br /> driver-specific cra_driver_name (e.g. "sha256-eip93") but passes<br /> CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.<br /> <br /> Since the EIP93 hash algorithms are the only ones registered<br /> under those driver names and they are inherently async, the<br /> lookup is self-contradictory and always fails with -ENOENT.<br /> <br /> When called from the AEAD setkey path, this failure leaves the<br /> SA record partially initialized with zeroed digest fields. A<br /> subsequent crypto operation then dereferences a NULL pointer in<br /> the request context, resulting in a kernel panic:<br /> <br /> ```<br /> pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]<br /> lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]<br /> sp : ffffffc082feb820<br /> x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980<br /> x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0<br /> x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000<br /> x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009<br /> x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0<br /> Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)<br /> ```<br /> <br /> The reported symbol eip93_aead_handle_result+0xc8c is a<br /> resolution artifact from static functions being merged under<br /> the nearest exported symbol. Decoding the faulting sequence:<br /> <br /> ```<br /> 910142b6 ADD X22, X21, #0x50<br /> f94012e0 LDR X0, [X23, #0x20]<br /> f9002aa0 STR X0, [X21, #0x50]<br /> f90006d3 STR X19, [X22, #0x8]<br /> f9400740 LDR X0, [X26, #0x8]<br /> ```<br /> <br /> The faulting LDR at [X26, #0x8] is loading ctx-&gt;flags<br /> (offset 8 in eip93_hash_ctx), where ctx has been resolved<br /> to NULL from a partially initialized or unreachable<br /> transform context following the failed setkey.<br /> <br /> Fix this by dropping the CRYPTO_ALG_ASYNC mask from the<br /> crypto_alloc_ahash() call. The code already handles async<br /> completion correctly via crypto_wait_req(), so there is no<br /> requirement to restrict the lookup to synchronous algorithms.<br /> <br /> Note that hashing a single 64-byte block through the hardware<br /> is likely slower than doing it in software due to the DMA<br /> round-trip overhead, but offloading it may still spare CPU<br /> cycles on the slower embedded cores where this IP is found.<br /> <br /> [Detailed investigation report of this bug]