Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: ensure safe queue release with state management<br /> <br /> Directly calling `put_queue` carries risks since it cannot<br /> guarantee that resources of `uacce_queue` have been fully released<br /> beforehand. So adding a `stop_queue` operation for the<br /> UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to<br /> the final resource release ensures safety.<br /> <br /> Queue states are defined as follows:<br /> - UACCE_Q_ZOMBIE: Initial state<br /> - UACCE_Q_INIT: After opening `uacce`<br /> - UACCE_Q_STARTED: After `start` is issued via `ioctl`<br /> <br /> When executing `poweroff -f` in virt while accelerator are still<br /> working, `uacce_fops_release` and `uacce_remove` may execute<br /> concurrently. This can cause `uacce_put_queue` within<br /> `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add<br /> state checks to prevent accessing freed pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel<br /> <br /> The connector type for the DataImage SCF0700C48GGU18 panel is missing and<br /> devm_drm_panel_bridge_add() requires connector type to be set. This leads<br /> to a warning and a backtrace in the kernel log and panel does not work:<br /> "<br /> WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8<br /> "<br /> The warning is triggered by a check for valid connector type in<br /> devm_drm_panel_bridge_add(). If there is no valid connector type<br /> set for a panel, the warning is printed and panel is not added.<br /> Fill in the missing connector type to fix the warning and make<br /> the panel operational once again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pNFS: Fix a deadlock when returning a delegation during open()<br /> <br /> Ben Coddington reports seeing a hang in the following stack trace:<br /> 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415<br /> 1 [ffffd0b50e177548] schedule at ffffffff9ca05717<br /> 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1<br /> 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb<br /> 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5<br /> 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]<br /> 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]<br /> 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]<br /> 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]<br /> 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]<br /> 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]<br /> 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]<br /> 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]<br /> 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]<br /> 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]<br /> 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]<br /> 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]<br /> 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea<br /> 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e<br /> 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935<br /> <br /> The issue is that the delegreturn is being asked to wait for a layout<br /> return that cannot complete because a state recovery was initiated. The<br /> state recovery cannot complete until the open() finishes processing the<br /> delegations it was given.<br /> <br /> The solution is to propagate the existing flags that indicate a<br /> non-blocking call to the function pnfs_roc(), so that it knows not to<br /> wait in this situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix drm panic null pointer when driver not support atomic<br /> <br /> When driver not support atomic, fb using plane-&gt;fb rather than<br /> plane-&gt;state-&gt;fb.<br /> <br /> (cherry picked from commit 2f2a72de673513247cd6fae14e53f6c40c5841ef)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Do not over-allocate ftrace memory<br /> <br /> The pg_remaining calculation in ftrace_process_locs() assumes that<br /> ENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the<br /> allocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE<br /> (integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.<br /> 4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)<br /> have significantly more capacity than 256 * 170. This leads to pg_remaining<br /> being underestimated, which in turn makes skip (derived from skipped -<br /> pg_remaining) larger than expected, causing the WARN(skip != remaining)<br /> to trigger.<br /> <br /> Extra allocated pages for ftrace: 2 with 654 skipped<br /> WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0<br /> <br /> A similar problem in ftrace_allocate_records() can result in allocating<br /> too many pages. This can trigger the second warning in<br /> ftrace_process_locs().<br /> <br /> Extra allocated pages for ftrace<br /> WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580<br /> <br /> Use the actual capacity of a page group to determine the number of pages<br /> to allocate. Have ftrace_allocate_pages() return the number of allocated<br /> pages to avoid having to calculate it. Use the actual page group capacity<br /> when validating the number of unused pages due to skipped entries.<br /> Drop the definition of ENTRIES_PER_PAGE since it is no longer used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a deadlock involving nfs_release_folio()<br /> <br /> Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery<br /> waiting on kthreadd, which is attempting to reclaim memory by calling<br /> nfs_release_folio(). The latter cannot make progress due to state<br /> recovery being needed.<br /> <br /> It seems that the only safe thing to do here is to kick off a writeback<br /> of the folio, without waiting for completion, or else kicking off an<br /> asynchronous commit.

A vulnerability in the Certificate Management feature of Cisco Meeting Management could allow an authenticated, remote attacker to upload arbitrary files, execute arbitrary commands, and elevate privileges to root on an affected system.<br /> <br /> This vulnerability is due to improper input validation in certain sections of the web-based management interface. An attacker could exploit this vulnerability&amp;nbsp;by sending a crafted HTTP request to an affected system. A successful exploit could allow the attacker to upload arbitrary files to the affected system. The malicious files could overwrite system files that are processed by the&amp;nbsp;root system account and allow arbitrary command execution with&amp;nbsp;root privileges. To exploit this vulnerability, the attacker must have valid credentials for a user account with at least the role of video operator.

A vulnerability in the web-based management interface of Cisco Prime Infrastructure could allow an authenticated, remote attacker to conduct a stored cross-site scripting (XSS) attack against users of the interface of an affected system.<br /> <br /> This vulnerability exists because the web-based management interface does not properly validate user-supplied input. An attacker could exploit this vulnerability by inserting malicious code into specific data fields in the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, an attacker must have valid administrative credentials.

A vulnerability in the text rendering subsystem of Cisco TelePresence Collaboration Endpoint (CE) Software and Cisco RoomOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.<br /> <br /> This vulnerability is due to insufficient validation of input received by an affected device. An attacker could exploit this vulnerability by getting the affected device to render crafted text, for example, a crafted meeting invitation. As indicated in the CVSS score, no user interaction is required, such as accepting the meeting invitation. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a DoS condition.

A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) and Cisco Prime Infrastructure could allow an unauthenticated, remote attacker to redirect a user to a malicious web page.<br /> <br /> This vulnerability is due to improper input validation of the parameters in the HTTP request. An attacker could exploit this vulnerability by intercepting and modifying an HTTP request from a user. A successful exploit could allow the attacker to redirect the user to a malicious web page.

A maliciously crafted project directory, when opening a max file in Autodesk 3ds Max, could lead to execution of arbitrary code in the context of the current process due to an Untrusted Search Path being utilized.

A vulnerability in the Dynamic Vectoring and Streaming (DVS) Engine implementation of Cisco AsyncOS Software for Cisco Secure Web Appliance could allow an unauthenticated, remote attacker to bypass the anti-malware scanner, allowing malicious archive files to be downloaded.<br /> <br /> This vulnerability is due to improper handling of certain archive files. An attacker could exploit this vulnerability by sending a crafted archive file, which should be blocked, through an affected device. A successful exploit could allow the attacker to bypass the anti-malware scanner and download malware onto an end user workstation. The downloaded malware will not automatically execute unless the end user extracts and launches the malicious file.&amp;nbsp;