Vulnerabilities

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 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 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;

A maliciously crafted RGB file, when parsed through Autodesk 3ds Max, can force a Memory Corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.

A maliciously crafted GIF file, when parsed through Autodesk 3ds Max, can force an Out-of-Bounds Write vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.

A maliciously crafted USD file, when loaded or imported into Autodesk Arnold or Autodesk 3ds Max, can force an Out-of-Bounds Write vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.

A maliciously crafted GIF file, when parsed through Autodesk 3ds Max, can cause a Stack-Based Buffer Overflow vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.

A maliciously crafted RGB file, when parsed through Autodesk 3ds Max, can force a Memory Corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom-qusb2: Fix NULL pointer dereference on early suspend<br /> <br /> Enabling runtime PM before attaching the QPHY instance as driver data<br /> can lead to a NULL pointer dereference in runtime PM callbacks that<br /> expect valid driver data. There is a small window where the suspend<br /> callback may run after PM runtime enabling and before runtime forbid.<br /> This causes a sporadic crash during boot:<br /> <br /> ```<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1<br /> [...]<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT<br /> Workqueue: pm pm_runtime_work<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]<br /> lr : pm_generic_runtime_suspend+0x2c/0x44<br /> [...]<br /> ```<br /> <br /> Attach the QPHY instance as driver data before enabling runtime PM to<br /> prevent NULL pointer dereference in runtime PM callbacks.<br /> <br /> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a<br /> short window where an unnecessary runtime suspend can occur.<br /> <br /> Use the devres-managed version to ensure PM runtime is symmetrically<br /> disabled during driver removal for proper cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock in wait_current_trans() due to ignored transaction type<br /> <br /> When wait_current_trans() is called during start_transaction(), it<br /> currently waits for a blocked transaction without considering whether<br /> the given transaction type actually needs to wait for that particular<br /> transaction state. The btrfs_blocked_trans_types[] array already defines<br /> which transaction types should wait for which transaction states, but<br /> this check was missing in wait_current_trans().<br /> <br /> This can lead to a deadlock scenario involving two transactions and<br /> pending ordered extents:<br /> <br /> 1. Transaction A is in TRANS_STATE_COMMIT_DOING state<br /> <br /> 2. A worker processing an ordered extent calls start_transaction()<br /> with TRANS_JOIN<br /> <br /> 3. join_transaction() returns -EBUSY because Transaction A is in<br /> TRANS_STATE_COMMIT_DOING<br /> <br /> 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes<br /> <br /> 5. A new Transaction B is created (TRANS_STATE_RUNNING)<br /> <br /> 6. The ordered extent from step 2 is added to Transaction B&amp;#39;s<br /> pending ordered extents<br /> <br /> 7. Transaction B immediately starts commit by another task and<br /> enters TRANS_STATE_COMMIT_START<br /> <br /> 8. The worker finally reaches wait_current_trans(), sees Transaction B<br /> in TRANS_STATE_COMMIT_START (a blocked state), and waits<br /> unconditionally<br /> <br /> 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START<br /> according to btrfs_blocked_trans_types[]<br /> <br /> 10. Transaction B is waiting for pending ordered extents to complete<br /> <br /> 11. Deadlock: Transaction B waits for ordered extent, ordered extent<br /> waits for Transaction B<br /> <br /> This can be illustrated by the following call stacks:<br /> CPU0 CPU1<br /> btrfs_finish_ordered_io()<br /> start_transaction(TRANS_JOIN)<br /> join_transaction()<br /> # -EBUSY (Transaction A is<br /> # TRANS_STATE_COMMIT_DOING)<br /> # Transaction A completes<br /> # Transaction B created<br /> # ordered extent added to<br /> # Transaction B&amp;#39;s pending list<br /> btrfs_commit_transaction()<br /> # Transaction B enters<br /> # TRANS_STATE_COMMIT_START<br /> # waiting for pending ordered<br /> # extents<br /> wait_current_trans()<br /> # waits for Transaction B<br /> # (should not wait!)<br /> <br /> Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered<br /> extents:<br /> <br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> btrfs_commit_transaction+0xbf7/0xda0 [btrfs]<br /> btrfs_sync_file+0x342/0x4d0 [btrfs]<br /> __x64_sys_fdatasync+0x4b/0x80<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Task kworker in wait_current_trans waiting for transaction commit:<br /> <br /> Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs]<br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> wait_current_trans+0xb0/0x110 [btrfs]<br /> start_transaction+0x346/0x5b0 [btrfs]<br /> btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]<br /> btrfs_work_helper+0xe8/0x350 [btrfs]<br /> process_one_work+0x1d3/0x3c0<br /> worker_thread+0x4d/0x3e0<br /> kthread+0x12d/0x150<br /> ret_from_fork+0x1f/0x30<br /> <br /> Fix this by passing the transaction type to wait_current_trans() and<br /> checking btrfs_blocked_trans_types[cur_trans-&gt;state] against the given<br /> type before deciding to wait. This ensures that transaction types which<br /> are allowed to join during certain blocked states will not unnecessarily<br /> wait and cause deadlocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: xilinx: xdma: Fix regmap max_register<br /> <br /> The max_register field is assigned the size of the register memory<br /> region instead of the offset of the last register.<br /> The result is that reading from the regmap via debugfs can cause<br /> a segmentation fault:<br /> <br /> tail /sys/kernel/debug/regmap/xdma.1.auto/registers<br /> Unable to handle kernel paging request at virtual address ffff800082f70000<br /> Mem abort info:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: level 3 translation fault<br /> [...]<br /> Call trace:<br /> regmap_mmio_read32le+0x10/0x30<br /> _regmap_bus_reg_read+0x74/0xc0<br /> _regmap_read+0x68/0x198<br /> regmap_read+0x54/0x88<br /> regmap_read_debugfs+0x140/0x380<br /> regmap_map_read_file+0x30/0x48<br /> full_proxy_read+0x68/0xc8<br /> vfs_read+0xcc/0x310<br /> ksys_read+0x7c/0x120<br /> __arm64_sys_read+0x24/0x40<br /> invoke_syscall.constprop.0+0x64/0x108<br /> do_el0_svc+0xb0/0xd8<br /> el0_svc+0x38/0x130<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> Code: aa1e03e9 d503201f f9400000 8b214000 (b9400000)<br /> ---[ end trace 0000000000000000 ]---<br /> note: tail[1217] exited with irqs disabled<br /> note: tail[1217] exited with preempt_count 1<br /> Segmentation fault