Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection<br /> <br /> The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL<br /> event_spec field, indicating support for IIO events. However, event<br /> detection is not supported for all sensors, and if userspace tries to<br /> configure accelerometer wakeup events on a sensor device that does not<br /> support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL<br /> pointer when trying to write to the wakeup register.<br /> Define an additional struct iio_chan_spec array whose members have a NULL<br /> event_spec field, and use this array instead of st_lsm6dsx_acc_channels for<br /> sensors without event detection capability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver<br /> <br /> at91_adc_interrupt can call at91_adc_touch_data_handler function<br /> to start the work by schedule_work(&amp;st-&gt;touch_st.workq).<br /> <br /> If we remove the module which will call at91_adc_remove to<br /> make cleanup, it will free indio_dev through iio_device_unregister but<br /> quite a bit later. While the work mentioned above will be used. The<br /> sequence of operations that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | at91_adc_workq_handler<br /> at91_adc_remove |<br /> iio_device_unregister(indio_dev) |<br /> //free indio_dev a bit later |<br /> | iio_push_to_buffers(indio_dev)<br /> | //use indio_dev<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in at91_adc_remove.

n8n is an open source workflow automation platform. From version 1.65.0 to before 1.114.3, the use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure. This issue has been patched in version 1.114.3.