Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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;=.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ena: fix missing lock when update devlink params<br /> <br /> Fix assert lock warning while calling devl_param_driverinit_value_set()<br /> in ena.<br /> <br /> WARNING: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9<br /> CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.19.0-rc2+ #1 PREEMPT(lazy)<br /> Hardware name: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:devl_assert_locked+0x62/0x90<br /> <br /> Call Trace:<br /> <br /> devl_param_driverinit_value_set+0x15/0x1c0<br /> ena_devlink_alloc+0x18c/0x220 [ena]<br /> ? __pfx_ena_devlink_alloc+0x10/0x10 [ena]<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? devm_ioremap_wc+0x9a/0xd0<br /> ena_probe+0x4d2/0x1b20 [ena]<br /> ? __lock_acquire+0x56a/0xbd0<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ? local_clock+0x15/0x30<br /> ? __lock_release.isra.0+0x1c9/0x340<br /> ? mark_held_locks+0x40/0x70<br /> ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ......<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: fix device mismatch in devm_kzalloc/devm_kfree<br /> <br /> Initial rss_hdr allocation uses virtio_device-&gt;device,<br /> but virtnet_set_queues() frees using net_device-&gt;device.<br /> This device mismatch causing below devres warning<br /> <br /> [ 3788.514041] ------------[ cut here ]------------<br /> [ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463<br /> [ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]<br /> [ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT<br /> [ 3788.514067] Tainted: [W]=WARN<br /> [ 3788.514069] Hardware name: Marvell CN106XX board (DT)<br /> [ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> [ 3788.514074] pc : devm_kfree+0x84/0x98<br /> [ 3788.514076] lr : devm_kfree+0x54/0x98<br /> [ 3788.514079] sp : ffff800084e2f220<br /> [ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f<br /> [ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080<br /> [ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018<br /> [ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000<br /> [ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff<br /> [ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff<br /> [ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c<br /> [ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f<br /> [ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080<br /> [ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 3788.514123] Call trace:<br /> [ 3788.514125] devm_kfree+0x84/0x98 (P)<br /> [ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]<br /> [ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]<br /> [ 3788.514139] virtio_dev_probe+0x1e0/0x338<br /> [ 3788.514144] really_probe+0xc8/0x3a0<br /> [ 3788.514149] __driver_probe_device+0x84/0x170<br /> [ 3788.514152] driver_probe_device+0x44/0x120<br /> [ 3788.514155] __device_attach_driver+0xc4/0x168<br /> [ 3788.514158] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514161] __device_attach+0xa4/0x1c0<br /> [ 3788.514164] device_initial_probe+0x1c/0x30<br /> [ 3788.514168] bus_probe_device+0xb4/0xc0<br /> [ 3788.514170] device_add+0x614/0x828<br /> [ 3788.514173] register_virtio_device+0x214/0x258<br /> [ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]<br /> [ 3788.514179] vdpa_dev_probe+0xa8/0xd8<br /> [ 3788.514183] really_probe+0xc8/0x3a0<br /> [ 3788.514186] __driver_probe_device+0x84/0x170<br /> [ 3788.514189] driver_probe_device+0x44/0x120<br /> [ 3788.514192] __device_attach_driver+0xc4/0x168<br /> [ 3788.514195] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514197] __device_attach+0xa4/0x1c0<br /> [ 3788.514200] device_initial_probe+0x1c/0x30<br /> [ 3788.514203] bus_probe_device+0xb4/0xc0<br /> [ 3788.514206] device_add+0x614/0x828<br /> [ 3788.514209] _vdpa_register_device+0x58/0x88<br /> [ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]<br /> [ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0<br /> [ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158<br /> [ 3788.514222] genl_rcv_msg+0x218/0x298<br /> [ 3788.514225] netlink_rcv_skb+0x64/0x138<br /> [ 3788.514229] genl_rcv+0x40/0x60<br /> [ 3788.514233] netlink_unicast+0x32c/0x3b0<br /> [ 3788.514237] netlink_sendmsg+0x170/0x3b8<br /> [ 3788.514241] __sys_sendto+0x12c/0x1c0<br /> [ 3788.514246] __arm64_sys_sendto+0x30/0x48<br /> [ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8<br /> [ 3788.514255] do_el0_svc+0x48/0xd0<br /> [ 3788.514259] el0_svc+0x48/0x210<br /> [ 3788.514264] el0t_64_sync_handler+0xa0/0xe8<br /> [ 3788.514268] el0t_64_sync+0x198/0x1a0<br /> [ 3788.514271] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix by using virtio_device-&gt;device consistently for<br /> allocation and deallocation