Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: legacy: ncm: Fix NPE in gncm_bind<br /> <br /> Commit 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle<br /> with bind/unbind") deferred the allocation of the net_device. This<br /> change leads to a NULL pointer dereference in the legacy NCM driver as<br /> it attempts to access the net_device before it&amp;#39;s fully instantiated.<br /> <br /> Store the provided qmult, host_addr, and dev_addr into the struct<br /> ncm_opts-&gt;net_opts during gncm_bind(). These values will be properly<br /> applied to the net_device when it is allocated and configured later in<br /> the binding process by the NCM function driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: Fix atomic context locking issue<br /> <br /> The ncm_set_alt function was holding a mutex to protect against races<br /> with configfs, which invokes the might-sleep function inside an atomic<br /> context.<br /> <br /> Remove the struct net_device pointer from the f_ncm_opts structure to<br /> eliminate the contention. The connection state is now managed by a new<br /> boolean flag to preserve the use-after-free fix from<br /> commit 6334b8e4553c ("usb: gadget: f_ncm: Fix UAF ncm object at re-bind<br /> after usb ep transport error").<br /> <br /> BUG: sleeping function called from invalid context<br /> Call Trace:<br /> dump_stack_lvl+0x83/0xc0<br /> dump_stack+0x14/0x16<br /> __might_resched+0x389/0x4c0<br /> __might_sleep+0x8e/0x100<br /> ...<br /> __mutex_lock+0x6f/0x1740<br /> ...<br /> ncm_set_alt+0x209/0xa40<br /> set_config+0x6b6/0xb40<br /> composite_setup+0x734/0x2b40<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling<br /> <br /> The `tpg-&gt;tpg_nexus` pointer in the USB Target driver is dynamically<br /> managed and tied to userspace configuration via ConfigFS. It can be<br /> NULL if the USB host sends requests before the nexus is fully<br /> established or immediately after it is dropped.<br /> <br /> Currently, functions like `bot_submit_command()` and the data<br /> transfer paths retrieve `tv_nexus = tpg-&gt;tpg_nexus` and immediately<br /> dereference `tv_nexus-&gt;tvn_se_sess` without any validation. If a<br /> malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)<br /> command during this race window, it triggers a NULL pointer<br /> dereference, leading to a kernel panic (local DoS).<br /> <br /> This exposes an inconsistent API usage within the module, as peer<br /> functions like `usbg_submit_command()` and `bot_send_bad_response()`<br /> correctly implement a NULL check for `tv_nexus` before proceeding.<br /> <br /> Fix this by bringing consistency to the nexus handling. Add the<br /> missing `if (!tv_nexus)` checks to the vulnerable BOT command and<br /> request processing paths, aborting the command gracefully with an<br /> error instead of crashing the system.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: image: mdc800: kill download URB on timeout<br /> <br /> mdc800_device_read() submits download_urb and waits for completion.<br /> If the timeout fires and the device has not responded, the function<br /> returns without killing the URB, leaving it active.<br /> <br /> A subsequent read() resubmits the same URB while it is still<br /> in-flight, triggering the WARN in usb_submit_urb():<br /> <br /> "URB submitted while active"<br /> <br /> Check the return value of wait_event_timeout() and kill the URB if<br /> it indicates timeout, ensuring the URB is complete before its status<br /> is inspected or the URB is resubmitted.<br /> <br /> Similar to<br /> - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling")<br /> - commit b98d5000c505 ("media: rc: iguanair: handle timeouts")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: renesas_usbhs: fix use-after-free in ISR during device removal<br /> <br /> In usbhs_remove(), the driver frees resources (including the pipe array)<br /> while the interrupt handler (usbhs_interrupt) is still registered. If an<br /> interrupt fires after usbhs_pipe_remove() but before the driver is fully<br /> unbound, the ISR may access freed memory, causing a use-after-free.<br /> <br /> Fix this by calling devm_free_irq() before freeing resources. This ensures<br /> the interrupt handler is both disabled and synchronized (waits for any<br /> running ISR to complete) before usbhs_pipe_remove() is called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: class: cdc-wdm: fix reordering issue in read code path<br /> <br /> Quoting the bug report:<br /> <br /> Due to compiler optimization or CPU out-of-order execution, the<br /> desc-&gt;length update can be reordered before the memmove. If this<br /> happens, wdm_read() can see the new length and call copy_to_user() on<br /> uninitialized memory. This also violates LKMM data race rules [1].<br /> <br /> Fix it by using WRITE_ONCE and memory barriers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Limit the length of unkillable synchronous timeouts<br /> <br /> The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in<br /> usbcore allow unlimited timeout durations. And since they use<br /> uninterruptible waits, this leaves open the possibility of hanging a<br /> task for an indefinitely long time, with no way to kill it short of<br /> unplugging the target device.<br /> <br /> To prevent this sort of problem, enforce a maximum limit on the length<br /> of these unkillable timeouts. The limit chosen here, somewhat<br /> arbitrarily, is 60 seconds. On many systems (although not all) this<br /> is short enough to avoid triggering the kernel&amp;#39;s hung-task detector.<br /> <br /> In addition, clear up the ambiguity of negative timeout values by<br /> treating them the same as 0, i.e., using the maximum allowed timeout.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start<br /> <br /> During ADSP stop and start, the kernel crashes due to the order in which<br /> ASoC components are removed.<br /> <br /> On ADSP stop, the q6apm-audio .remove callback unloads topology and removes<br /> PCM runtimes during ASoC teardown. This deletes the RTDs that contain the<br /> q6apm DAI components before their removal pass runs, leaving those<br /> components still linked to the card and causing crashes on the next rebind.<br /> <br /> Fix this by ensuring that all dependent (child) components are removed<br /> first, and the q6apm component is removed last.<br /> <br /> [ 48.105720] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0<br /> [ 48.114763] Mem abort info:<br /> [ 48.117650] ESR = 0x0000000096000004<br /> [ 48.121526] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 48.127010] SET = 0, FnV = 0<br /> [ 48.130172] EA = 0, S1PTW = 0<br /> [ 48.133415] FSC = 0x04: level 0 translation fault<br /> [ 48.138446] Data abort info:<br /> [ 48.141422] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 48.147079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 48.152354] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 48.157859] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001173cf000<br /> [ 48.164517] [00000000000000d0] pgd=0000000000000000, p4d=0000000000000000<br /> [ 48.171530] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 48.177348] Modules linked in: q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm 8021q garp mrp stp llc snd_soc_hdmi_codec apr pdr_interface phy_qcom_edp fastrpc qcom_pd_mapper rpmsg_ctrl qrtr_smd rpmsg_char qcom_pdr_msg qcom_iris v4l2_mem2mem videobuf2_dma_contig ath11k_pci msm ubwc_config at24 ath11k videobuf2_memops mac80211 ocmem videobuf2_v4l2 libarc4 drm_gpuvm mhi qrtr videodev drm_exec snd_soc_sc8280xp gpu_sched videobuf2_common nvmem_qcom_spmi_sdam snd_soc_qcom_sdw drm_dp_aux_bus qcom_q6v5_pas qcom_spmi_temp_alarm snd_soc_qcom_common rtc_pm8xxx qcom_pon drm_display_helper cec qcom_pil_info qcom_stats soundwire_bus drm_client_lib mc dispcc0_sa8775p videocc_sa8775p qcom_q6v5 camcc_sa8775p snd_soc_dmic phy_qcom_sgmii_eth snd_soc_max98357a i2c_qcom_geni snd_soc_core dwmac_qcom_ethqos llcc_qcom icc_bwmon qcom_sysmon snd_compress qcom_refgen_regulator coresight_stm stmmac_platform snd_pcm_dmaengine qcom_common coresight_tmc stmmac coresight_replicator qcom_glink_smem coresight_cti stm_core<br /> [ 48.177444] coresight_funnel snd_pcm ufs_qcom phy_qcom_qmp_usb gpi phy_qcom_snps_femto_v2 coresight phy_qcom_qmp_ufs qcom_wdt gpucc_sa8775p pcs_xpcs mdt_loader qcom_ice icc_osm_l3 qmi_helpers snd_timer snd soundcore display_connector qcom_rng nvmem_reboot_mode drm_kms_helper phy_qcom_qmp_pcie sha256 cfg80211 rfkill socinfo fuse drm backlight ipv6<br /> [ 48.301059] CPU: 2 UID: 0 PID: 293 Comm: kworker/u32:2 Not tainted 6.19.0-rc6-dirty #10 PREEMPT<br /> [ 48.310081] Hardware name: Qualcomm Technologies, Inc. Lemans EVK (DT)<br /> [ 48.316782] Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface]<br /> [ 48.323672] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 48.330825] pc : mutex_lock+0xc/0x54<br /> [ 48.334514] lr : soc_dapm_shutdown_dapm+0x44/0x174 [snd_soc_core]<br /> [ 48.340794] sp : ffff800084ddb7b0<br /> [ 48.344207] x29: ffff800084ddb7b0 x28: ffff00009cd9cf30 x27: ffff00009cd9cc00<br /> [ 48.351544] x26: ffff000099610190 x25: ffffa31d2f19c810 x24: ffffa31d2f185098<br /> [ 48.358869] x23: ffff800084ddb7f8 x22: 0000000000000000 x21: 00000000000000d0<br /> [ 48.366198] x20: ffff00009ba6c338 x19: ffff00009ba6c338 x18: 00000000ffffffff<br /> [ 48.373528] x17: 000000040044ffff x16: ffffa31d4ae6dca8 x15: 072007740775076f<br /> [ 48.380853] x14: 0765076d07690774 x13: 00313a323a656369 x12: 767265733a637673<br /> [ 48.388182] x11: 00000000000003f9 x10: ffffa31d4c7dea98 x9 : 0000000000000001<br /> [ 48.395519] x8 : ffff00009a2aadc0 x7 : 0000000000000003 x6 : 0000000000000000<br /> [ 48.402854] x5 : 0000000000000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Fix NULL pointer exception during user_scan()<br /> <br /> user_scan() invokes updated sas_user_scan() for channel 0, and if<br /> successful, iteratively scans remaining channels (1 to shost-&gt;max_channel)<br /> via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix<br /> sas_user_scan() to handle wildcard and multi-channel scans"). However,<br /> hisi_sas supports only one channel, and the current value of max_channel is<br /> 1. sas_user_scan() for channel 1 will trigger the following NULL pointer<br /> exception:<br /> <br /> [ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0<br /> [ 441.554699] Mem abort info:<br /> [ 441.554710] ESR = 0x0000000096000004<br /> [ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 441.554723] SET = 0, FnV = 0<br /> [ 441.554726] EA = 0, S1PTW = 0<br /> [ 441.554730] FSC = 0x04: level 0 translation fault<br /> [ 441.554735] Data abort info:<br /> [ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000<br /> [ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000<br /> [ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod<br /> [ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT<br /> [ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118<br /> [ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118<br /> [ 441.707502] sp : ffff80009abbba40<br /> [ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08<br /> [ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00<br /> [ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000<br /> [ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020<br /> [ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff<br /> [ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a<br /> [ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4<br /> [ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030<br /> [ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000<br /> [ 441.782053] Call trace:<br /> [ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P)<br /> [ 441.789095] sas_target_alloc+0x24/0xb0<br /> [ 441.792920] scsi_alloc_target+0x290/0x330<br /> [ 441.797010] __scsi_scan_target+0x88/0x258<br /> [ 441.801096] scsi_scan_channel+0x74/0xb8<br /> [ 441.805008] scsi_scan_host_selected+0x170/0x188<br /> [ 441.809615] sas_user_scan+0xfc/0x148<br /> [ 441.813267] store_scan+0x10c/0x180<br /> [ 441.816743] dev_attr_store+0x20/0x40<br /> [ 441.820398] sysfs_kf_write+0x84/0xa8<br /> [ 441.824054] kernfs_fop_write_iter+0x130/0x1c8<br /> [ 441.828487] vfs_write+0x2c0/0x370<br /> [ 441.831880] ksys_write+0x74/0x118<br /> [ 441.835271] __arm64_sys_write+0x24/0x38<br /> [ 441.839182] invoke_syscall+0x50/0x120<br /> [ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0<br /> [ 441.847611] do_el0_svc+0x24/0x38<br /> [ 441.850913] el0_svc+0x38/0x158<br /> [ 441.854043] el0t_64_sync_handler+0xa0/0xe8<br /> [ 441.858214] el0t_64_sync+0x1ac/0x1b0<br /> [ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)<br /> [ 441.867946] ---[ end trace 0000000000000000 ]---<br /> <br /> Therefore<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Completely fix fcport double free<br /> <br /> In qla24xx_els_dcmd_iocb() sp-&gt;free is set to qla2x00_els_dcmd_sp_free().<br /> When an error happens, this function is called by qla2x00_sp_release(),<br /> when kref_put() releases the first and the last reference.<br /> <br /> qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport().<br /> Doing it one more time after kref_put() is a bad idea.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend<br /> <br /> In __ufshcd_wl_suspend(), cancel_delayed_work_sync() is called to cancel<br /> the UFS RTC work, but it is placed after ufshcd_vops_suspend(hba, pm_op,<br /> POST_CHANGE). This creates a race condition where ufshcd_rtc_work() can<br /> still be running while ufshcd_vops_suspend() is executing. When<br /> UFSHCD_CAP_CLK_GATING is not supported, the condition<br /> !hba-&gt;clk_gating.active_reqs is always true, causing ufshcd_update_rtc()<br /> to be executed. Since ufshcd_vops_suspend() typically performs clock<br /> gating operations, executing ufshcd_update_rtc() at that moment triggers<br /> an SError. The kernel panic trace is as follows:<br /> <br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> Call trace:<br /> dump_backtrace+0xec/0x128<br /> show_stack+0x18/0x28<br /> dump_stack_lvl+0x40/0xa0<br /> dump_stack+0x18/0x24<br /> panic+0x148/0x374<br /> nmi_panic+0x3c/0x8c<br /> arm64_serror_panic+0x64/0x8c<br /> do_serror+0xc4/0xc8<br /> el1h_64_error_handler+0x34/0x4c<br /> el1h_64_error+0x68/0x6c<br /> el1_interrupt+0x20/0x58<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x68/0x6c<br /> ktime_get+0xc4/0x12c<br /> ufshcd_mcq_sq_stop+0x4c/0xec<br /> ufshcd_mcq_sq_cleanup+0x64/0x1dc<br /> ufshcd_clear_cmd+0x38/0x134<br /> ufshcd_issue_dev_cmd+0x298/0x4d0<br /> ufshcd_exec_dev_cmd+0x1a4/0x1c4<br /> ufshcd_query_attr+0xbc/0x19c<br /> ufshcd_rtc_work+0x10c/0x1c8<br /> process_scheduled_works+0x1c4/0x45c<br /> worker_thread+0x32c/0x3e8<br /> kthread+0x120/0x1d8<br /> ret_from_fork+0x10/0x20<br /> <br /> Fix this by moving cancel_delayed_work_sync() before the call to<br /> ufshcd_vops_suspend(hba, pm_op, PRE_CHANGE), ensuring the UFS RTC work is<br /> fully completed or cancelled at that point.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc, perf: Check that current-&gt;mm is alive before getting user callchain<br /> <br /> It may happen that mm is already released, which leads to kernel panic.<br /> This adds the NULL check for current-&gt;mm, similarly to<br /> commit 20afc60f892d ("x86, perf: Check that current-&gt;mm is alive before getting user callchain").<br /> <br /> I was getting this panic when running a profiling BPF program<br /> (profile.py from bcc-tools):<br /> <br /> [26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0)<br /> [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588<br /> [26215.051952] Faulting instruction address: 0xc00000000020fac0<br /> [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1]<br /> [...]<br /> [26215.052049] Call Trace:<br /> [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490 (unreliable)<br /> [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30<br /> [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360<br /> [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0<br /> [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274<br /> [...]<br /> <br /> In addition, move storing the top-level stack entry to generic<br /> perf_callchain_user to make sure the top-evel entry is always captured,<br /> even if current-&gt;mm is NULL.<br /> <br /> [Maddy: fixed message to avoid checkpatch format style error]