Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()<br /> <br /> KASAN reported a stack-out-of-bounds access in ima_appraise_measurement<br /> from is_bprm_creds_for_exec:<br /> <br /> BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0<br /> Read of size 1 at addr ffffc9000160f940 by task sudo/550<br /> The buggy address belongs to stack of task sudo/550<br /> and is located at offset 24 in frame:<br /> ima_appraise_measurement+0x0/0x16a0<br /> This frame has 2 objects:<br /> [48, 56) &amp;#39;file&amp;#39;<br /> [80, 148) &amp;#39;hash&amp;#39;<br /> <br /> This is caused by using container_of on the *file pointer. This offset<br /> calculation is what triggers the stack-out-of-bounds error.<br /> <br /> In order to fix this, pass in a bprm_is_check boolean which can be set<br /> depending on how process_measurement is called. If the caller has a<br /> linux_binprm pointer and the function is BPRM_CHECK we can determine<br /> is_check and set it then. Otherwise set it to false.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix NULL pointer dereference on panthor_fw_unplug<br /> <br /> This patch removes the MCU halt and wait for halt procedures during<br /> panthor_fw_unplug() as the MCU can be in a variety of states or the FW<br /> may not even be loaded/initialized at all, the latter of which can lead<br /> to a NULL pointer dereference.<br /> <br /> It should be safe on unplug to just disable the MCU without waiting for<br /> it to halt as it may not be able to.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix potential NULL pointer dereference in context cleanup<br /> <br /> aie_destroy_context() is invoked during error handling in<br /> aie2_create_context(). However, aie_destroy_context() assumes that the<br /> context&amp;#39;s mailbox channel pointer is non-NULL. If mailbox channel<br /> creation fails, the pointer remains NULL and calling aie_destroy_context()<br /> can lead to a NULL pointer dereference.<br /> <br /> In aie2_create_context(), replace aie_destroy_context() with a function<br /> which request firmware to remove the context created previously.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: fix deadlock in ni_read_folio_cmpr<br /> <br /> Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr).<br /> This is caused by a lock inversion deadlock involving the inode mutex<br /> (ni_lock) and page locks.<br /> <br /> Scenario:<br /> 1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock.<br /> 2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in<br /> the compressed frame (including page Y).<br /> 3. Concurrently, Task B (e.g., via readahead) has locked page Y and<br /> calls ntfs_read_folio().<br /> 4. Task B waits for ni_lock (held by A).<br /> 5. Task A waits for page Y lock (held by B).<br /> -&gt; DEADLOCK.<br /> <br /> The fix is to restructure locking: do not take ni_lock in ntfs_read_folio().<br /> Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required<br /> page locks for the frame have been successfully acquired. This restores the<br /> correct lock ordering (Page Lock -&gt; ni_lock) consistent with VFS.<br /> <br /> [almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Initialize new folios before use<br /> <br /> KMSAN reports an uninitialized value in longest_match_std(), invoked<br /> from ntfs_compress_write(). When new folios are allocated without being<br /> marked uptodate and ni_read_frame() is skipped because the caller expects<br /> the frame to be completely overwritten, some reserved folios may remain<br /> only partially filled, leaving the rest memory uninitialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: fix ntfs_mount_options leak in ntfs_fill_super()<br /> <br /> In ntfs_fill_super(), the fc-&gt;fs_private pointer is set to NULL without<br /> first freeing the memory it points to. This causes the subsequent call to<br /> ntfs_fs_free() to skip freeing the ntfs_mount_options structure.<br /> <br /> This results in a kmemleak report:<br /> <br /> unreferenced object 0xff1100015378b800 (size 32):<br /> comm "mount", pid 582, jiffies 4294890685<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 ed ff ed ff 00 04 00 00 ................<br /> backtrace (crc ed541d8c):<br /> __kmalloc_cache_noprof+0x424/0x5a0<br /> __ntfs_init_fs_context+0x47/0x590<br /> alloc_fs_context+0x5d8/0x960<br /> __x64_sys_fsopen+0xb1/0x190<br /> do_syscall_64+0x50/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> This issue can be reproduced using the following commands:<br /> fallocate -l 100M test.file<br /> mount test.file /tmp/test<br /> <br /> Since sbi-&gt;options is duplicated from fc-&gt;fs_private and does not<br /> directly use the memory allocated for fs_private, it is unnecessary to<br /> set fc-&gt;fs_private to NULL.<br /> <br /> Additionally, this patch simplifies the code by utilizing the helper<br /> function put_mount_options() instead of open-coding the cleanup logic.

*** Pendiente de traducción *** IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 is vulnerable to a denial of service with a specially crafted query when autonomous transactions are enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix race condition when checking rpm_on<br /> <br /> When autosuspend is triggered, driver rpm_on flag is set to indicate that<br /> a suspend/resume is already in progress. However, when a userspace<br /> application submits a command during this narrow window,<br /> amdxdna_pm_resume_get() may incorrectly skip the resume operation because<br /> the rpm_on flag is still set. This results in commands being submitted<br /> while the device has not actually resumed, causing unexpected behavior.<br /> <br /> The set_dpm() is called by suspend/resume, it relied on rpm_on flag to<br /> avoid calling into rpm suspend/resume recursivly. So to fix this, remove<br /> the use of the rpm_on flag entirely. Instead, introduce aie2_pm_set_dpm()<br /> which explicitly resumes the device before invoking set_dpm(). With this<br /> change, set_dpm() is called directly inside the suspend or resume execution<br /> path. Otherwise, aie2_pm_set_dpm() is called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: /smack/doi: accept previously used values<br /> <br /> Writing to /smack/doi a value that has ever been<br /> written there in the past disables networking for<br /> non-ambient labels.<br /> E.g.<br /> <br /> # cat /smack/doi<br /> 3<br /> # netlabelctl -p cipso list<br /> Configured CIPSO mappings (1)<br /> DOI value : 3<br /> mapping type : PASS_THROUGH<br /> # netlabelctl -p map list<br /> Configured NetLabel domain mappings (3)<br /> domain: "_" (IPv4)<br /> protocol: UNLABELED<br /> domain: DEFAULT (IPv4)<br /> protocol: CIPSO, DOI = 3<br /> domain: DEFAULT (IPv6)<br /> protocol: UNLABELED<br /> <br /> # cat /smack/ambient<br /> _<br /> # cat /proc/$$/attr/smack/current<br /> _<br /> # ping -c1 10.1.95.12<br /> 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms<br /> # echo foo &gt;/proc/$$/attr/smack/current<br /> # ping -c1 10.1.95.12<br /> 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms<br /> unknown option 86<br /> <br /> # echo 4 &gt;/smack/doi<br /> # echo 3 &gt;/smack/doi<br /> !&gt; [ 214.050395] smk_cipso_doi:691 cipso add rc = -17<br /> # echo 3 &gt;/smack/doi<br /> !&gt; [ 249.402261] smk_cipso_doi:678 remove rc = -2<br /> !&gt; [ 249.402261] smk_cipso_doi:691 cipso add rc = -17<br /> <br /> # ping -c1 10.1.95.12<br /> !!&gt; ping: 10.1.95.12: Address family for hostname not supported<br /> <br /> # echo _ &gt;/proc/$$/attr/smack/current<br /> # ping -c1 10.1.95.12<br /> 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms<br /> <br /> This happens because Smack keeps decommissioned DOIs,<br /> fails to re-add them, and consequently refuses to add<br /> the “default” domain map:<br /> <br /> # netlabelctl -p cipso list<br /> Configured CIPSO mappings (2)<br /> DOI value : 3<br /> mapping type : PASS_THROUGH<br /> DOI value : 4<br /> mapping type : PASS_THROUGH<br /> # netlabelctl -p map list<br /> Configured NetLabel domain mappings (2)<br /> domain: "_" (IPv4)<br /> protocol: UNLABELED<br /> !&gt; (no ipv4 map for default domain here)<br /> domain: DEFAULT (IPv6)<br /> protocol: UNLABELED<br /> <br /> Fix by clearing decommissioned DOI definitions and<br /> serializing concurrent DOI updates with a new lock.<br /> <br /> Also:<br /> - allow /smack/doi to live unconfigured, since<br /> adding a map (netlbl_cfg_cipsov4_map_add) may fail.<br /> CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI<br /> - add new DOI before removing the old default map,<br /> so the old map remains if the add fails<br /> <br /> (2008-02-04, Casey Schaufler)

*** Pendiente de traducción *** IBM Cognos Analytics 11.2.0, 11.2.4, 12.0, and 12.1.0 and IBM Cognos Transformer 11.2.4, 12.0, and 12.1.0 are vulnerable to cross-site scripting (XSS). This vulnerability allows a remote attacker to inject arbitrary JavaScript code into the web user interface, which may alter the intended functionality and could lead to the disclosure of credentials within a trusted session.

*** Pendiente de traducción *** IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 002 could allow a privileged user to upload a malicious backup archive that could be restored and used to gain access to the underlying operating system.

*** Pendiente de traducción *** IBM SDI 7.2.0.0 through 7.2.0.14 and IBM Security Directory Integrator 10.0.0.0 through 10.0.0.2 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.