Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove()<br /> <br /> In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it<br /> may be NULL:<br /> <br /> if (!jdi)<br /> mipi_dsi_detach(dsi);<br /> <br /> However, when jdi is NULL, the function does not return and continues by<br /> calling jdi_panel_disable():<br /> <br /> err = jdi_panel_disable(&amp;jdi-&gt;base);<br /> <br /> Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can<br /> lead to a NULL-pointer dereference:<br /> <br /> struct jdi_panel *jdi = to_panel_jdi(panel);<br /> backlight_disable(jdi-&gt;backlight);<br /> <br /> To prevent such a potential NULL-pointer dereference, return early from<br /> jdi_panel_dsi_remove() when jdi is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()<br /> <br /> [BUG]<br /> There is a bug report that when btrfs hits ENOSPC error in a critical<br /> path, btrfs flips RO (this part is expected, although the ENOSPC bug<br /> still needs to be addressed).<br /> <br /> The problem is after the RO flip, if there is a read repair pending, we<br /> can hit the ASSERT() inside btrfs_repair_io_failure() like the following:<br /> <br /> BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1<br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -28)<br /> WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844<br /> Modules linked in: kvm_intel kvm irqbypass<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> BTRFS info (device vdc state EA): 2 enospc errors during balance<br /> BTRFS info (device vdc state EA): balance: ended with status: -30<br /> BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6<br /> BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0<br /> [...]<br /> assertion failed: !(fs_info-&gt;sb-&gt;s_flags &amp; SB_RDONLY) :: 0, in fs/btrfs/bio.c:938<br /> ------------[ cut here ]------------<br /> assertion failed: !(fs_info-&gt;sb-&gt;s_flags &amp; SB_RDONLY) :: 0, in fs/btrfs/bio.c:938<br /> kernel BUG at fs/btrfs/bio.c:938!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full)<br /> Tainted: [W]=WARN, [N]=TEST<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> Workqueue: btrfs-endio simple_end_io_work<br /> RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120<br /> RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246<br /> RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff<br /> RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988<br /> R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310<br /> R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000<br /> FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> ------------[ cut here ]------------<br /> <br /> [CAUSE]<br /> The cause of -ENOSPC error during the test case btrfs/124 is still<br /> unknown, although it&amp;#39;s known that we still have cases where metadata can<br /> be over-committed but can not be fulfilled correctly, thus if we hit<br /> such ENOSPC error inside a critical path, we have no choice but abort<br /> the current transaction.<br /> <br /> This will mark the fs read-only.<br /> <br /> The problem is inside the btrfs_repair_io_failure() path that we require<br /> the fs not to be mount read-only. This is normally fine, but if we are<br /> doing a read-repair meanwhile the fs flips RO due to a critical error,<br /> we can enter btrfs_repair_io_failure() with super block set to<br /> read-only, thus triggering the above crash.<br /> <br /> [FIX]<br /> Just replace the ASSERT() with a proper return if the fs is already<br /> read-only.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: nci: Fix parameter validation for packet data<br /> <br /> Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for<br /> packet data") communication with nci nfc chips is not working any more.<br /> <br /> The mentioned commit tries to fix access of uninitialized data, but<br /> failed to understand that in some cases the data packet is of variable<br /> length and can therefore not be compared to the maximum packet length<br /> given by the sizeof(struct).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Return queued buffers on start_streaming() failure<br /> <br /> Return buffers if streaming fails to start due to uvc_pm_get() error.<br /> <br /> This bug may be responsible for a warning I got running<br /> <br /> while :; do yavta -c3 /dev/video0; done<br /> <br /> on an xHCI controller which failed under this workload.<br /> I had no luck reproducing this warning again to confirm.<br /> <br /> xhci_hcd 0000:09:00.0: HC died; cleaning up<br /> usb 13-2: USB disconnect, device number 2<br /> WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Skip vcn poison irq release on VF<br /> <br /> VF doesn&amp;#39;t enable VCN poison irq in VCNv2.5. Skip releasing it and avoid<br /> call trace during deinitialization.<br /> <br /> [ 71.913601] [drm] clean up the vf2pf work item<br /> [ 71.915088] ------------[ cut here ]------------<br /> [ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu]<br /> [ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev serio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha256_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cryptd<br /> [ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.8.0-87-generic #88~22.04.1-Ubuntu<br /> [ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014<br /> [ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu]<br /> [ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00<br /> [ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246<br /> [ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 0000000000000000<br /> [ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 0000000000000000<br /> [ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda480000<br /> [ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000<br /> [ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:0000000000000000<br /> [ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 0000000000770ef0<br /> [ 71.915800] PKRU: 55555554<br /> [ 71.915802] Call Trace:<br /> [ 71.915805] <br /> [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init()<br /> <br /> rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is<br /> unsupported or invalid. rga_buf_init() does not check the return value<br /> and unconditionally dereferences the pointer when accessing f-&gt;size.<br /> <br /> Add proper ERR_PTR checking and return the error to prevent<br /> dereferencing an invalid pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Workaround SQM/PSE stalls by disabling sticky<br /> <br /> NIX SQ manager sticky mode is known to cause stalls when multiple SQs<br /> share an SMQ and transmit concurrently. Additionally, PSE may deadlock<br /> on transitions between sticky and non-sticky transmissions. There is<br /> also a credit drop issue observed when certain condition clocks are<br /> gated.<br /> <br /> work around these hardware errata by:<br /> - Disabling SQM sticky operation:<br /> - Clear TM6 (bit 15)<br /> - Clear TM11 (bit 14)<br /> - Disabling sticky → non-sticky transition path that can deadlock PSE:<br /> - Clear TM5 (bit 23)<br /> - Preventing credit drops by keeping the control-flow clock enabled:<br /> - Set TM9 (bit 21)<br /> <br /> These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this<br /> configuration the SQM/PSE maintain forward progress under load without<br /> credit loss, at the cost of disabling sticky optimizations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()<br /> <br /> When idtab allocation fails, net is not registered with rio_add_net() yet,<br /> so kfree(net) is sufficient to release the memory. Set mport-&gt;net to NULL<br /> to avoid dangling pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panels<br /> <br /> Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")<br /> we may get the following kernel panic, for some panels, when rebooting:<br /> <br /> systemd-shutdown[1]: Rebooting.<br /> Call trace:<br /> ...<br /> do_serror+0x28/0x68<br /> el1h_64_error_handler+0x34/0x50<br /> el1h_64_error+0x6c/0x70<br /> rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)<br /> mipi_dsi_device_transfer+0x44/0x58<br /> mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4<br /> ili9881c_unprepare+0x38/0x88<br /> drm_panel_unprepare+0xbc/0x108<br /> <br /> This happens for panels that need to send MIPI-DSI commands in their<br /> unprepare() callback. Since the MIPI-DSI interface is stopped at that<br /> point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic.<br /> <br /> Fix by moving rzg2l_mipi_dsi_stop() to new callback function<br /> rzg2l_mipi_dsi_atomic_post_disable().<br /> <br /> With this change we now have the correct power-down/stop sequence:<br /> <br /> systemd-shutdown[1]: Rebooting.<br /> rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry<br /> ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry<br /> rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry<br /> reboot: Restarting system

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix kthread worker destruction in polling mode<br /> <br /> Fix the cleanup order in polling mode (irq work_list)) and<br /> WARN_ON(!list_empty(&amp;worker-&gt;delayed_work_list)).<br /> <br /> The original code called kthread_destroy_worker() before hrtimer_cancel(),<br /> creating a race condition where the timer could fire during worker<br /> destruction and queue new work, triggering the WARN_ON.<br /> <br /> This causes the following warning on every module unload in polling mode:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430<br /> kthread_destroy_worker+0x84/0x98<br /> Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ...<br /> Call trace:<br /> kthread_destroy_worker+0x84/0x98<br /> wave5_vpu_remove+0xc8/0xe0 [wave5]<br /> platform_remove+0x30/0x58<br /> ...<br /> ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node<br /> <br /> When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during<br /> vmalloc cleanup triggers expensive stack unwinding that acquires RCU read<br /> locks. Processing a large purge_list without rescheduling can cause the<br /> task to hold CPU for extended periods (10+ seconds), leading to RCU stalls<br /> and potential OOM conditions.<br /> <br /> The issue manifests in purge_vmap_node() -&gt; kasan_release_vmalloc_node()<br /> where iterating through hundreds or thousands of vmap_area entries and<br /> freeing their associated shadow pages causes:<br /> <br /> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l<br /> ...<br /> task:kworker/0:17 state:R running task stack:28840 pid:6229<br /> ...<br /> kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299<br /> purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299<br /> <br /> Each call to kasan_release_vmalloc() can free many pages, and with<br /> page_owner tracking, each free triggers save_stack() which performs stack<br /> unwinding under RCU read lock. Without yielding, this creates an<br /> unbounded RCU critical section.<br /> <br /> Add periodic cond_resched() calls within the loop to allow:<br /> - RCU grace periods to complete<br /> - Other tasks to run<br /> - Scheduler to preempt when needed<br /> <br /> The fix uses need_resched() for immediate response under load, with a<br /> batch count of 32 as a guaranteed upper bound to prevent worst-case stalls<br /> even under light load.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kexec: derive purgatory entry from symbol<br /> <br /> kexec_load_purgatory() derives image-&gt;start by locating e_entry inside an<br /> SHF_EXECINSTR section. If the purgatory object contains multiple<br /> executable sections with overlapping sh_addr, the entrypoint check can<br /> match more than once and trigger a WARN.<br /> <br /> Derive the entry section from the purgatory_start symbol when present and<br /> compute image-&gt;start from its final placement. Keep the existing e_entry<br /> fallback for purgatories that do not expose the symbol.<br /> <br /> WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784<br /> Call Trace:<br /> <br /> bzImage64_load+0x133/0xa00<br /> __do_sys_kexec_file_load+0x2b3/0x5c0<br /> do_syscall_64+0x81/0x610<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> [me@linux.beauty: move helper to avoid forward declaration, per Baoquan]