Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Change AMDGPU_VA_RESERVED_TRAP_SIZE to 64KB<br /> <br /> Currently, AMDGPU_VA_RESERVED_TRAP_SIZE is hardcoded to 8KB, while<br /> KFD_CWSR_TBA_TMA_SIZE is defined as 2 * PAGE_SIZE. On systems with<br /> 4K pages, both values match (8KB), so allocation and reserved space<br /> are consistent.<br /> <br /> However, on 64K page-size systems, KFD_CWSR_TBA_TMA_SIZE becomes 128KB,<br /> while the reserved trap area remains 8KB. This mismatch causes the<br /> kernel to crash when running rocminfo or rccl unit tests.<br /> <br /> Kernel attempted to read user page (2) - exploit attempt? (uid: 1001)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000002<br /> Faulting instruction address: 0xc0000000002c8a64<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E<br /> 6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006<br /> of:IBM,FW1060.30 (ML1060_896) hv:phyp pSeries<br /> NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730<br /> REGS: c0000001e0957580 TRAP: 0300 Tainted: G E<br /> MSR: 8000000000009033 CR: 24008268<br /> XER: 00000036<br /> CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000<br /> IRQMASK: 1<br /> GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100<br /> c00000013d814540<br /> GPR04: 0000000000000002 c00000013d814550 0000000000000045<br /> 0000000000000000<br /> GPR08: c00000013444d000 c00000013d814538 c00000013d814538<br /> 0000000084002268<br /> GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff<br /> 0000000000020000<br /> GPR16: 0000000000000000 0000000000000002 c00000015f653000<br /> 0000000000000000<br /> GPR20: c000000138662400 c00000013d814540 0000000000000000<br /> c00000013d814500<br /> GPR24: 0000000000000000 0000000000000002 c0000001e0957888<br /> c0000001e0957878<br /> GPR28: c00000013d814548 0000000000000000 c00000013d814540<br /> c0000001e0957888<br /> NIP [c0000000002c8a64] __mutex_add_waiter+0x24/0xc0<br /> LR [c00000000125dbc8] __mutex_lock.constprop.0+0x318/0xd00<br /> Call Trace:<br /> 0xc0000001e0957890 (unreliable)<br /> __mutex_lock.constprop.0+0x58/0xd00<br /> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x6fc/0xb60 [amdgpu]<br /> kfd_process_alloc_gpuvm+0x54/0x1f0 [amdgpu]<br /> kfd_process_device_init_cwsr_dgpu+0xa4/0x1a0 [amdgpu]<br /> kfd_process_device_init_vm+0xd8/0x2e0 [amdgpu]<br /> kfd_ioctl_acquire_vm+0xd0/0x130 [amdgpu]<br /> kfd_ioctl+0x514/0x670 [amdgpu]<br /> sys_ioctl+0x134/0x180<br /> system_call_exception+0x114/0x300<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> This patch changes AMDGPU_VA_RESERVED_TRAP_SIZE to 64 KB and<br /> KFD_CWSR_TBA_TMA_SIZE to the AMD GPU page size. This means we reserve<br /> 64 KB for the trap in the address space, but only allocate 8 KB within<br /> it. With this approach, the allocation size never exceeds the reserved<br /> area.<br /> <br /> (cherry picked from commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dsi: Don&amp;#39;t do DSC horizontal timing adjustments in command mode<br /> <br /> Stop adjusting the horizontal timing values based on the<br /> compression ratio in command mode. Bspec seems to be telling<br /> us to do this only in video mode, and this is also how the<br /> Windows driver does things.<br /> <br /> This should also fix a div-by-zero on some machines because<br /> the adjusted htotal ends up being so small that we end up with<br /> line_time_us==0 when trying to determine the vtotal value in<br /> command mode.<br /> <br /> Note that this doesn&amp;#39;t actually make the display on the<br /> Huawei Matebook E work, but at least the kernel no longer<br /> explodes when the driver loads.<br /> <br /> (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbtmc: Flush anchored URBs in usbtmc_release<br /> <br /> When calling usbtmc_release, pending anchored URBs must be flushed or<br /> killed to prevent use-after-free errors (e.g. in the HCD giveback<br /> path). Call usbtmc_draw_down() to allow anchored URBs to be completed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: br_nd_send: validate ND option lengths<br /> <br /> br_nd_send() walks ND options according to option-provided lengths.<br /> A malformed option can make the parser advance beyond the computed<br /> option span or use a too-short source LLADDR option payload.<br /> <br /> Validate option lengths against the remaining NS option area before<br /> advancing, and only read source LLADDR when the option is large enough<br /> for an Ethernet address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> auxdisplay: line-display: fix NULL dereference in linedisp_release<br /> <br /> linedisp_release() currently retrieves the enclosing struct linedisp via<br /> to_linedisp(). That lookup depends on the attachment list, but the<br /> attachment may already have been removed before put_device() invokes the<br /> release callback. This can happen in linedisp_unregister(), and can also<br /> be reached from some linedisp_register() error paths.<br /> <br /> In that case, to_linedisp() returns NULL and linedisp_release()<br /> dereferences it while freeing the display resources.<br /> <br /> The struct device released here is the embedded linedisp-&gt;dev used by<br /> linedisp_register(), so retrieve the enclosing object directly with<br /> container_of() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: gadget: fix state inconsistency on gadget init failure<br /> <br /> When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode<br /> while software state remains INACTIVE, creating hardware/software state<br /> inconsistency.<br /> <br /> When switching to host mode via sysfs:<br /> echo host &gt; /sys/class/usb_role/13180000.usb-role-switch/role<br /> <br /> The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,<br /> so cdns_role_stop() skips cleanup because state is still INACTIVE.<br /> This violates the DRD controller design specification (Figure22),<br /> which requires returning to idle state before switching roles.<br /> <br /> This leads to a synchronous external abort in xhci_gen_setup() when<br /> setting up the host controller:<br /> <br /> [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19<br /> [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget<br /> [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed<br /> ...<br /> [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller<br /> [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP<br /> [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408<br /> [ 1301.393391] backtrace:<br /> ...<br /> xhci_gen_setup+0xa4/0x408

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: gadget: fix NULL pointer dereference in ep_queue<br /> <br /> When the gadget endpoint is disabled or not yet configured, the ep-&gt;desc<br /> pointer can be NULL. This leads to a NULL pointer dereference when<br /> __cdns3_gadget_ep_queue() is called, causing a kernel crash.<br /> <br /> Add a check to return -ESHUTDOWN if ep-&gt;desc is NULL, which is the<br /> standard return code for unconfigured endpoints.<br /> <br /> This prevents potential crashes when ep_queue is called on endpoints<br /> that are not ready.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()<br /> <br /> dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro,<br /> which expects hsotg-&gt;lock to be held since it does spin_unlock/spin_lock<br /> around the gadget driver callback invocation.<br /> <br /> However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating()<br /> without holding the lock. This leads to:<br /> - spin_unlock on a lock that is not held (undefined behavior)<br /> - The lock remaining held after dwc2_gadget_exit_clock_gating() returns,<br /> causing a deadlock when spin_lock_irqsave() is called later in the<br /> same function.<br /> <br /> Fix this by acquiring hsotg-&gt;lock before calling<br /> dwc2_gadget_exit_clock_gating() and releasing it afterwards, which<br /> satisfies the locking requirement of the call_gadget() macro.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: Fix URB memory leak on submit failure<br /> <br /> When usb_submit_urb() fails in usbio_probe(), the previously allocated<br /> URB is never freed, causing a memory leak.<br /> <br /> Fix this by jumping to err_free_urb label to properly release the URB<br /> on the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: ulpi: fix double free in ulpi_register_interface() error path<br /> <br /> When device_register() fails, ulpi_register() calls put_device() on<br /> ulpi-&gt;dev.<br /> <br /> The device release callback ulpi_dev_release() drops the OF node<br /> reference and frees ulpi, but the current error path in<br /> ulpi_register_interface() then calls kfree(ulpi) again, causing a<br /> double free.<br /> <br /> Let put_device() handle the cleanup through ulpi_dev_release() and<br /> avoid freeing ulpi again in ulpi_register_interface().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy<br /> <br /> Buffer size used in dma allocation and memcpy is wrong.<br /> It can lead to undersized DMA buffer access and possible<br /> memory corruption. use correct buffer size in dma_alloc_coherent<br /> and memcpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: EM: Fix NULL pointer dereference when perf domain ID is not found<br /> <br /> dev_energymodel_nl_get_perf_domains_doit() calls<br /> em_perf_domain_get_by_id() but does not check the return value before<br /> passing it to __em_nl_get_pd_size(). When a caller supplies a<br /> non-existent perf domain ID, em_perf_domain_get_by_id() returns NULL,<br /> and __em_nl_get_pd_size() immediately dereferences pd-&gt;cpus<br /> (struct offset 0x30), causing a NULL pointer dereference.<br /> <br /> The sister handler dev_energymodel_nl_get_perf_table_doit() already<br /> handles this correctly via __em_nl_get_pd_table_id(), which returns<br /> NULL and causes the caller to return -EINVAL. Add the same NULL check<br /> in the get-perf-domains do handler.<br /> <br /> [ rjw: Subject and changelog edits ]