Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/display/dp_mst: Add protection against 0 vcpi<br /> <br /> When releasing a timeslot there is a slight chance we may end up<br /> with the wrong payload mask due to overflow if the delayed_destroy_work<br /> ends up coming into play after a DP 2.1 monitor gets disconnected<br /> which causes vcpi to become 0 then we try to make the payload =<br /> ~BIT(vcpi - 1) which is a negative shift. VCPI id should never<br /> really be 0 hence skip changing the payload mask if VCPI is 0.<br /> <br /> Otherwise it leads to<br /> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc<br /> [drm_display_helper]] port ffff888126ce9000 (3)<br /> [515.287267] -----------[ cut here ]-----------<br /> [515.287268] UBSAN: shift-out-of-bounds in<br /> ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36<br /> [515.287271] shift exponent -1 is negative<br /> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G<br /> S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary)<br /> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P<br /> WIFI, BIOS 1645 03/15/2024<br /> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work<br /> [drm_display_helper]<br /> [515.287303] Call Trace:<br /> [515.287304] <br /> [515.287306] dump_stack_lvl+0xc1/0xf0<br /> [515.287313] dump_stack+0x10/0x20<br /> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0<br /> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0<br /> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d<br /> [drm_display_helper]<br /> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe]<br /> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0<br /> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60<br /> [515.287562] intel_atomic_check+0x119/0x2b80 [xe]<br /> [515.287740] ? find_held_lock+0x31/0x90<br /> [515.287747] ? lock_release+0xce/0x2a0<br /> [515.287754] drm_atomic_check_only+0x6a2/0xb40<br /> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140<br /> [515.287765] drm_atomic_commit+0x6e/0xf0<br /> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10<br /> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0<br /> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0<br /> [515.287795] ? mutex_lock_nested+0x1b/0x30<br /> [515.287801] drm_client_modeset_commit+0x26/0x50<br /> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110<br /> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140<br /> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0<br /> [515.287819] drm_client_hotplug+0x6c/0xf0<br /> [515.287824] drm_client_dev_hotplug+0x9e/0xd0<br /> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30<br /> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410<br /> [drm_display_helper]<br /> [515.287861] process_one_work+0x22b/0x6f0<br /> [515.287874] worker_thread+0x1e8/0x3d0<br /> [515.287879] ? __pfx_worker_thread+0x10/0x10<br /> [515.287882] kthread+0x11c/0x250<br /> [515.287886] ? __pfx_kthread+0x10/0x10<br /> [515.287890] ret_from_fork+0x2d7/0x310<br /> [515.287894] ? __pfx_kthread+0x10/0x10<br /> [515.287897] ret_from_fork_asm+0x1a/0x30

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.

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.

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.

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]

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.

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.

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.

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.

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)

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.

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.