Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: stm32-usphyc: Fix off by one in probe()<br /> <br /> The "index" variable is used as an index into the usbphyc-&gt;phys[] array<br /> which has usbphyc-&gt;nphys elements. So if it is equal to usbphyc-&gt;nphys<br /> then it is one element out of bounds. The "index" comes from the<br /> device tree so it&amp;#39;s data that we trust and it&amp;#39;s unlikely to be wrong,<br /> however it&amp;#39;s obviously still worth fixing the bug. Change the &gt; to &gt;=.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> w1: therm: Fix off-by-one buffer overflow in alarms_store<br /> <br /> The sysfs buffer passed to alarms_store() is allocated with &amp;#39;size + 1&amp;#39;<br /> bytes and a NUL terminator is appended. However, the &amp;#39;size&amp;#39; argument<br /> does not account for this extra byte. The original code then allocated<br /> &amp;#39;size&amp;#39; bytes and used strcpy() to copy &amp;#39;buf&amp;#39;, which always writes one<br /> byte past the allocated buffer since strcpy() copies until the NUL<br /> terminator at index &amp;#39;size&amp;#39;.<br /> <br /> Fix this by parsing the &amp;#39;buf&amp;#39; parameter directly using simple_strtoll()<br /> without allocating any intermediate memory or string copying. This<br /> removes the overflow while simplifying the code.