Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> via_wdt: fix critical boot hang due to unnamed resource allocation<br /> <br /> The VIA watchdog driver uses allocate_resource() to reserve a MMIO<br /> region for the watchdog control register. However, the allocated<br /> resource was not given a name, which causes the kernel resource tree<br /> to contain an entry marked as "" under /proc/iomem on x86<br /> platforms.<br /> <br /> During boot, this unnamed resource can lead to a critical hang because<br /> subsequent resource lookups and conflict checks fail to handle the<br /> invalid entry properly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: make decode_pool() more resilient against corrupted osdmaps<br /> <br /> If the osdmap is (maliciously) corrupted such that the encoded length<br /> of ceph_pg_pool envelope is less than what is expected for a particular<br /> encoding version, out-of-bounds reads may ensue because the only bounds<br /> check that is there is based on that length value.<br /> <br /> This patch adds explicit bounds checks for each field that is decoded<br /> or skipped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Avoid walking the Namespace if start_node is NULL<br /> <br /> Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace<br /> if it is not there") fixed the situation when both start_node and<br /> acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed<br /> on Honor Magicbook 14 Pro [1].<br /> <br /> That happens due to the access to the member of parent_node in<br /> acpi_ns_get_next_node(). The NULL pointer dereference will always<br /> happen, no matter whether or not the start_node is equal to<br /> ACPI_ROOT_OBJECT, so move the check of start_node being NULL<br /> out of the if block.<br /> <br /> Unfortunately, all the attempts to contact Honor have failed, they<br /> refused to provide any technical support for Linux.<br /> <br /> The bad DSDT table&amp;#39;s dump could be found on GitHub [2].<br /> <br /> DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025<br /> <br /> [ rjw: Subject adjustment, changelog edits ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf<br /> <br /> A zero length gss_token results in pages == 0 and in_token-&gt;pages[0]<br /> is NULL. The code unconditionally evaluates<br /> page_address(in_token-&gt;pages[0]) for the initial memcpy, which can<br /> dereference NULL even when the copy length is 0. Guard the first<br /> memcpy so it only runs when length &gt; 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Do not reprogram affinitiy on ASP chip<br /> <br /> The ASP chip is a very old variant of the GSP chip and is used e.g. in<br /> HP 730 workstations. When trying to reprogram the affinity it will crash<br /> with a HPMC as the relevant registers don&amp;#39;t seem to be at the usual<br /> location. Let&amp;#39;s avoid the crash by checking the sversion. Also note,<br /> that reprogramming isn&amp;#39;t necessary either, as the HP730 is a just a<br /> single-CPU machine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: reset KASAN tag in defer_free() before accessing freed memory<br /> <br /> When CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free()<br /> before defer_free(). On ARM64 with MTE (Memory Tagging Extension),<br /> kasan_slab_free() poisons the memory and changes the tag from the<br /> original (e.g., 0xf3) to a poison tag (0xfe).<br /> <br /> When defer_free() then tries to write to the freed object to build the<br /> deferred free list via llist_add(), the pointer still has the old tag,<br /> causing a tag mismatch and triggering a KASAN use-after-free report:<br /> <br /> BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537<br /> Write at addr f3f000000854f020 by task kworker/u8:6/983<br /> Pointer tag: [f3], memory tag: [fe]<br /> <br /> Fix this by calling kasan_reset_tag() before accessing the freed memory.<br /> This is safe because defer_free() is part of the allocator itself and is<br /> expected to manipulate freed memory for bookkeeping purposes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83791d) Convert macros to functions to avoid TOCTOU<br /> <br /> The macro FAN_FROM_REG evaluates its arguments multiple times. When used<br /> in lockless contexts involving shared driver data, this leads to<br /> Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially<br /> causing divide-by-zero errors.<br /> <br /> Convert the macro to a static function. This guarantees that arguments<br /> are evaluated only once (pass-by-value), preventing the race<br /> conditions.<br /> <br /> Additionally, in store_fan_div, move the calculation of the minimum<br /> limit inside the update lock. This ensures that the read-modify-write<br /> sequence operates on consistent data.<br /> <br /> Adhere to the principle of minimal changes by only converting macros<br /> that evaluate arguments multiple times and are used in lockless<br /> contexts.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add VLAN id validation before using<br /> <br /> Currently, the VLAN id may be used without validation when<br /> receive a VLAN configuration mailbox from VF. The length of<br /> vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause<br /> out-of-bounds memory access once the VLAN id is bigger than<br /> or equal to VLAN_N_VID.<br /> <br /> Therefore, VLAN id needs to be checked to ensure it is within<br /> the range of VLAN_N_VID.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - zero initialize memory allocated via sock_kmalloc<br /> <br /> Several crypto user API contexts and requests allocated with<br /> sock_kmalloc() were left uninitialized, relying on callers to<br /> set fields explicitly. This resulted in the use of uninitialized<br /> data in certain error paths or when new fields are added in the<br /> future.<br /> <br /> The ACVP patches also contain two user-space interface files:<br /> algif_kpp.c and algif_akcipher.c. These too rely on proper<br /> initialization of their context structures.<br /> <br /> A particular issue has been observed with the newly added<br /> &amp;#39;inflight&amp;#39; variable introduced in af_alg_ctx by commit:<br /> <br /> 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")<br /> <br /> Because the context is not memset to zero after allocation,<br /> the inflight variable has contained garbage values. As a result,<br /> af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when<br /> the garbage value was interpreted as true:<br /> <br /> https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209<br /> <br /> The check directly tests ctx-&gt;inflight without explicitly<br /> comparing against true/false. Since inflight is only ever set to<br /> true or false later, an uninitialized value has triggered<br /> -EBUSY failures. Zero-initializing memory allocated with<br /> sock_kmalloc() ensures inflight and other fields start in a known<br /> state, removing random issues caused by uninitialized data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: adreno: fix deferencing ifpc_reglist when not declared<br /> <br /> On plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist<br /> if still deferenced in a7xx_patch_pwrup_reglist() which causes<br /> a kernel crash:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> ...<br /> pc : a6xx_hw_init+0x155c/0x1e4c [msm]<br /> lr : a6xx_hw_init+0x9a8/0x1e4c [msm]<br /> ...<br /> Call trace:<br /> a6xx_hw_init+0x155c/0x1e4c [msm] (P)<br /> msm_gpu_hw_init+0x58/0x88 [msm]<br /> adreno_load_gpu+0x94/0x1fc [msm]<br /> msm_open+0xe4/0xf4 [msm]<br /> drm_file_alloc+0x1a0/0x2e4 [drm]<br /> drm_client_init+0x7c/0x104 [drm]<br /> drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]<br /> drm_client_setup+0xb4/0xd8 [drm_client_lib]<br /> msm_drm_kms_post_init+0x2c/0x3c [msm]<br /> msm_drm_init+0x1a4/0x228 [msm]<br /> msm_drm_bind+0x30/0x3c [msm]<br /> ...<br /> <br /> Check the validity of ifpc_reglist before deferencing the table<br /> to setup the register values.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/688944/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: PM: Fix reverse check in filesystems_freeze_callback()<br /> <br /> The freeze_all_ptr check in filesystems_freeze_callback() introduced by<br /> commit a3f8f8662771 ("power: always freeze efivarfs") is reverse which<br /> quite confusingly causes all file systems to be frozen when<br /> filesystem_freeze_enabled is false.<br /> <br /> On my systems it causes the WARN_ON_ONCE() in __set_task_frozen() to<br /> trigger, most likely due to an attempt to freeze a file system that is<br /> not ready for that.<br /> <br /> Add a logical negation to the check in question to reverse it as<br /> appropriate.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: ensure node page reads complete before f2fs_put_super() finishes<br /> <br /> Xfstests generic/335, generic/336 sometimes crash with the following message:<br /> <br /> F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/super.c:1939!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_put_super+0x3b3/0x3c0<br /> Call Trace:<br /> <br /> generic_shutdown_super+0x7e/0x190<br /> kill_block_super+0x1a/0x40<br /> kill_f2fs_super+0x9d/0x190<br /> deactivate_locked_super+0x30/0xb0<br /> cleanup_mnt+0xba/0x150<br /> task_work_run+0x5c/0xa0<br /> exit_to_user_mode_loop+0xb7/0xc0<br /> do_syscall_64+0x1ae/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> It appears that sometimes it is possible that f2fs_put_super() is called before<br /> all node page reads are completed.<br /> Adding a call to f2fs_wait_on_all_pages() for F2FS_RD_NODE fixes the problem.