Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: enforce device_lock for driver_match_device()<br /> <br /> Currently, driver_match_device() is called from three sites. One site<br /> (__device_attach_driver) holds device_lock(dev), but the other two<br /> (bind_store and __driver_attach) do not. This inconsistency means that<br /> bus match() callbacks are not guaranteed to be called with the lock<br /> held.<br /> <br /> Fix this by introducing driver_match_device_locked(), which guarantees<br /> holding the device lock using a scoped guard. Replace the unlocked calls<br /> in bind_store() and __driver_attach() with this new helper. Also add a<br /> lock assertion to driver_match_device() to enforce this guarantee.<br /> <br /> This consistency also fixes a known race condition. The driver_override<br /> implementation relies on the device_lock, so the missing lock led to the<br /> use-after-free (UAF) reported in Bugzilla for buses using this field.<br /> <br /> Stress testing the two newly locked paths for 24 hours with<br /> CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence<br /> and no lockdep warnings.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: omap: do not register driver in probe()<br /> <br /> Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the<br /> omap_mpuio_driver from omap_mpuio_init(), which is called from<br /> omap_gpio_probe().<br /> <br /> However, it neither makes sense to register drivers from probe()<br /> callbacks of other drivers, nor does the driver core allow registering<br /> drivers with a device lock already being held.<br /> <br /> The latter was revealed by commit dc23806a7c47 ("driver core: enforce<br /> device_lock for driver_match_device()") leading to a potential deadlock<br /> condition described in [1].<br /> <br /> Additionally, the omap_mpuio_driver is never unregistered from the<br /> driver core, even if the module is unloaded.<br /> <br /> Hence, register the omap_mpuio_driver from the module initcall and<br /> unregister it in module_exit().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: remove napi_synchronize() in igb_down()<br /> <br /> When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),<br /> the XSK buffer pool is destroyed but NAPI polling continues.<br /> igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing<br /> napi_complete_done() from clearing NAPI_STATE_SCHED.<br /> <br /> igb_down() calls napi_synchronize() before napi_disable() for each queue<br /> vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,<br /> which never happens. igb_down() blocks indefinitely, the TX watchdog<br /> fires, and the TX queue remains permanently stalled.<br /> <br /> napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.<br /> After a full-budget poll, __napi_poll() checks napi_disable_pending(). If<br /> set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop<br /> that napi_synchronize() cannot.<br /> <br /> napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible<br /> panic caused by Rx traffic arrival while interface is down").<br /> napi_disable() provides stronger guarantees: it prevents further<br /> scheduling and waits for any active poll to exit.<br /> Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a<br /> preceding napi_synchronize() in their down paths.<br /> <br /> Remove redundant napi_synchronize() call and reorder napi_disable()<br /> before igb_set_queue_napi() so the queue-to-NAPI mapping is only<br /> cleared after polling has fully stopped.

*** Pendiente de traducción *** The Fan Control application V251 contains an improper privilege handling vulnerability in its Open File Dialog. The dialog processes user-supplied paths with elevated permissions, which can be exploited by a local attacker to perform actions with administrator-level privileges.

*** Pendiente de traducción *** Dell Alienware Command Center (AWCC), versions prior to 6.13.8.0, contain an Execution with Unnecessary Privileges vulnerability in the AWCC. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kasan: fix double free for kasan pXds<br /> <br /> kasan_free_pxd() assumes the page table is always struct page aligned. <br /> But that&amp;#39;s not always the case for all architectures. E.g. In case of<br /> powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache<br /> named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let&amp;#39;s just<br /> directly pass the start of the pxd table which is passed as the 1st<br /> argument.<br /> <br /> This fixes the below double free kasan issue seen with PMEM:<br /> <br /> radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages<br /> ==================================================================<br /> BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20<br /> Free of addr c0000003c38e0000 by task ndctl/2164<br /> <br /> CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY<br /> Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries<br /> Call Trace:<br /> dump_stack_lvl+0x88/0xc4 (unreliable)<br /> print_report+0x214/0x63c<br /> kasan_report_invalid_free+0xe4/0x110<br /> check_slab_allocation+0x100/0x150<br /> kmem_cache_free+0x128/0x6e0<br /> kasan_remove_zero_shadow+0x9c4/0xa20<br /> memunmap_pages+0x2b8/0x5c0<br /> devm_action_release+0x54/0x70<br /> release_nodes+0xc8/0x1a0<br /> devres_release_all+0xe0/0x140<br /> device_unbind_cleanup+0x30/0x120<br /> device_release_driver_internal+0x3e4/0x450<br /> unbind_store+0xfc/0x110<br /> drv_attr_store+0x78/0xb0<br /> sysfs_kf_write+0x114/0x140<br /> kernfs_fop_write_iter+0x264/0x3f0<br /> vfs_write+0x3bc/0x7d0<br /> ksys_write+0xa4/0x190<br /> system_call_exception+0x190/0x480<br /> system_call_vectored_common+0x15c/0x2ec<br /> ---- interrupt: 3000 at 0x7fff93b3d3f4<br /> NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000<br /> REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392)<br /> MSR: 800000000280f033 CR: 48888208 XER: 00000000<br /> <br /> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4<br /> LR [00007fff93b3d3f4] 0x7fff93b3d3f4<br /> ---- interrupt: 3000<br /> <br /> The buggy address belongs to the object at c0000003c38e0000<br /> which belongs to the cache pgtable-2^9 of size 4096<br /> The buggy address is located 0 bytes inside of<br /> 4096-byte region [c0000003c38e0000, c0000003c38e1000)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c<br /> head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> memcg:c0000003bfd63e01<br /> flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff)<br /> page_type: f5(slab)<br /> raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000<br /> raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01<br /> head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000<br /> head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01<br /> head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff<br /> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004<br /> page dumped because: kasan: bad access detected<br /> <br /> [ 138.953636] [ T2164] Memory state around the buggy address:<br /> [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953661] [ T2164] &gt;c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953669] [ T2164] ^<br /> [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953692] [ T2164] ==================================================================<br /> [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint

*** Pendiente de traducción *** A flaw has been found in Totolink A8000RU 7.1cu.643_b20200521. This issue affects the function setWiFiAclRules of the file /cgi-bin/cstecgi.cgi of the component CGI Handler. This manipulation of the argument mode causes os command injection. The attack is possible to be carried out remotely. The exploit has been published and may be used.

*** Pendiente de traducción *** A vulnerability has been found in Totolink A8000RU 7.1cu.643_b20200521. Impacted is the function CsteSystem of the file /cgi-bin/cstecgi.cgi of the component CGI Handler. Such manipulation of the argument HTTP leads to os command injection. The attack may be performed from remote. The exploit has been disclosed to the public and may be used.

*** Pendiente de traducción *** A vulnerability was determined in Wooey up to 0.13.2. The impacted element is the function add_or_update_script of the file wooey/api/scripts.py of the component API Endpoint. Executing a manipulation can lead to improper authorization. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 0.13.3rc1 and 0.14.0 is sufficient to resolve this issue. This patch is called f7846fc0c323da8325422cab32623491757f1b88. The affected component should be upgraded.

*** Pendiente de traducción *** A vulnerability was found in vllm up to 0.19.0. The affected element is the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. Performing a manipulation results in uninitialized resource. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The patch is named 1ad67864c0c20f167929e64c875f5c28e1aad9fd. To fix this issue, it is recommended to deploy a patch.

*** Pendiente de traducción *** Cross Site Request Forgery vulnerability in diskoverdata diskover-community v.2.3.5. and before allows a remote attacker to escalate privileges and obtain sensitive information via the public/settings_process.php

*** Pendiente de traducción *** A reflected cross-site scripting (XSS) vulnerability exists in diskover-community