drm/amd/display: guard dc_sink dereferences in MST mode validation
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: guard dc_sink dereferences in MST mode validation
dm_dp_mst_is_port_support_mode() reads
aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check,
and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads
aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL
check. dc_sink is cleared asynchronously on MST unplug, and both
functions run from paths that the driver's own comments document as
racing that teardown: the connector probe worker's ->mode_valid
callback and a compositor's atomic check, neither of which holds the
MST manager lo
drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend
dc_state_create_copy() can return NULL on allocation failure.
dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts()
and continues execution, returning success. dm_resume() then
dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the
following dc_state->stream_count loop, crashing during GPU reset
recovery.
Return -ENOMEM immediately if the copy fails, so the caller aborts
suspend instead of leaving a NULL cached state for resume.
(cherry picked from commit 84b6d7932fdd285779
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx6: fix firmware leak on teardown
The firmware requested in gfx_v6_0_init_microcode() is not released
when the GFX block is torn down, leaking the firmware resources.
Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini()
to release the PFP, ME, CE and RLC firmware.
(cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924)
drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device
platform_device_register_data() can fail and return an ERR_PTR, but the
return value is used without checking, leading to an invalid pointer
being stored in ddp_comp[].dev and passed to component_match_add() and
mtk_ddp_comp_init(), which could result in a kernel crash.
Add an IS_ERR() check to jump to the error handling path on failure.
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix ovl adaptor platform device leak
mtk_drm_probe() creates an OVL adaptor platform device with
platform_device_register_data() when the display pipeline requires the
OVL adaptor.
If a later initialization step fails, the probe error path releases
the DRM resources without unregistering the already registered OVL
adaptor device. The normal remove path likewise leaves the device
registered after the DRM driver is unbound.
Keep track of whether the OVL adaptor was successfully registered and
unregister it on probe failure. Also recover the platform device fro
drm/mediatek: Fix pdev reference leak in mtk_drm_bind()
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix pdev reference leak in mtk_drm_bind()
When the device is not the mmsys master, mtk_drm_bind() returns early
after taking a reference on the disp-mutex device via
of_find_device_by_node(), without ever dropping it: mtk_drm_unbind()
only puts mutex_dev for the master. Drop the reference before returning
from the non-master path.
drm/amdgpu: fix IP instance memory leak on kobject add failure
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix IP instance memory leak on kobject add failure
amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with
kzalloc_flex() and initializes its embedded kobject before calling
kobject_add().
If kobject_add() fails, the return value is ignored and execution
continues without dropping the initial kobject reference. The failed
kobject is not retained in the kset list, so the normal sysfs teardown
path cannot find it. As a result, ip_hw_instance_release() is never
called and the ip_hw_instance allocation is leaked.
Call kobject_put() when kobject_add() fails so t
drm/amdgpu: fix ACP MFD device leak on init failure
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ACP MFD device leak on init failure
acp_hw_init() registers ACP child devices with mfd_add_devices() before
attaching them to the ACP power domain and initializing the hardware.
If attaching a child to the power domain fails, or if the ACP reset or
clock enable operation times out, the failure path frees only the
source cell, resource, and platform-data allocations. The child
platform devices already registered by mfd_add_devices() remain
registered and are never released.
Remove the children from the power domain and unregister the MFD
devices on failures
binder: fix is_failure flag for superseded transaction cleanup
In the Linux kernel, the following vulnerability has been resolved:
binder: fix is_failure flag for superseded transaction cleanup
When a TF_UPDATE_TXN transaction supersedes a pending async transaction,
binder_release_entire_buffer() is called with is_failure=false. Since the
superseded transaction was never delivered, binder_apply_fd_fixups() was
never called and no fds were installed in the target process.
With is_failure=false, the BINDER_TYPE_FDA cleanup handler interprets
stale buffer contents as installed fd numbers and passes them to
binder_deferred_fd_close(), closing unrelated file descriptors.
Pass is_failure=true since the tra
binder: fix leaked fd fixups on TF_UPDATE_TXN supersede
In the Linux kernel, the following vulnerability has been resolved:
binder: fix leaked fd fixups on TF_UPDATE_TXN supersede
When a TF_UPDATE_TXN transaction supersedes a pending async transaction
in a frozen process, the outdated transaction is freed with kfree()
directly. This skips binder_free_txn_fixups(), leaking all
binder_txn_fd_fixup entries and their fget()'d struct file references.
The leaked file refcounts never reach zero, so the struct file objects
are permanently pinned in memory. They survive process exit and
accumulate across invocations until file-max exhaustion.
Every other transaction cleanup path (binder_free_transactio
In the Linux kernel, the following vulnerability has been resolved:
binderfs: fix UAF write in binder_add_device
binderfs_binder_device_create() publishes the new dentry with
d_make_persistent() and then calls simple_done_creating(), which drops
the parent directory lock and the creator's dentry reference. It then
calls binder_add_device() to register the device in the global
binder_devices list.
After simple_done_creating() releases the parent directory lock, a
concurrent unlinkat() can remove the new device entry. Dropping the
creator's dentry reference can then trigger binderfs_evict_inode(),
freeing the device. binder_add_device() late
nitro_enclaves: fix use-after-free on SLOT_ALLOC failure
In the Linux kernel, the following vulnerability has been resolved:
nitro_enclaves: fix use-after-free on SLOT_ALLOC failure
When ne_create_vm_ioctl() fails the SLOT_ALLOC request after
anon_inode_getfile() has succeeded, the error path calls
fput(enclave_file) and then frees ne_enclave.
In normal userspace context, fput() defers the final __fput() via
task_work. ne_enclave_release() therefore runs after ne_enclave has
already been freed and dereferences ne_enclave->slot_uid, causing a
use-after-free: KASAN: slab-use-after-free in ne_enclave_release.
The enclave has no slot allocated and is not yet linked into the
enclaves list on this er
rust_binder: cancel deferred work items in thread exit
In the Linux kernel, the following vulnerability has been resolved:
rust_binder: cancel deferred work items in thread exit
If there are deferred work items on the thread todo list, then they are
not cleaned up in the Thread::release() method. Thus, update the code to
clean up the work items even if they are deferred.
This can happen if the thread dies while it has an active outgoing
transaction.
USB: cdc-acm: skip URB restart in port_shutdown if disconnected
In the Linux kernel, the following vulnerability has been resolved:
USB: cdc-acm: skip URB restart in port_shutdown if disconnected
acm_port_shutdown() is called from the tty-port machinery whenever the
last user closes the port. acm_disconnect() sets acm->disconnected and
calls tty_port_tty_vhangup(), which eventually triggers port_shutdown().
At that point acm_disconnect() has already called acm_poison_urbs() and
is about to free the control and read URBs.
However, acm_port_shutdown() unconditionally calls acm_unpoison_urbs()
and, when the ALWAYS_POLL_CTRL quirk is set, immediately re-submits the
ctrlurb and all read URBs. If the concu
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: fix port tear down use-after-free
Some drivers for multiport devices access port driver data from
completion handlers of shared URBs submitted at attach() or first open()
and stopped at disconnect() or last close(), respectively.
A simple NULL check before accessing the driver data makes sure that a
port state container has at least been allocated, but a completion
handler can still race with port tear down.
Reorder the disconnect handling so that ports are not deregistered (and
their driver data freed) until after all ports have been hung up and the
driver d
usb: storage: sierra_ms: reject short SWoC info transfers
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: sierra_ms: reject short SWoC info transfers
sierra_get_swoc_info() requests sizeof(struct swoc_info) (60) bytes
from the device via usb_control_msg(), but its callers only treat a
negative return value as failure. A device that answers the
vendor-specific GetSwocInfo request with a short IN transfer is
therefore accepted, leaving the tail of the freshly allocated
(kmalloc(), non-zeroing) swoc_info buffer uninitialized.
truinst_show() subsequently prints swocInfo->rev, swocInfo->LinuxSKU
and swocInfo->LinuxVer from that buffer into the world-readable
(0444) "t
usb: gadget: midi2: Fix the jack descriptor array sizes
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: midi2: Fix the jack descriptor array sizes
The jack in/out descriptor arrays in struct f_midi2_usb_config have
the size of MAX_CABLES, which look reasonable -- but it turned out to
be incorrect. Namely, the entries for those arrays are added from
both inputs and outputs, hence for each loop cycle, it adds two, ended
up with as twice as the expected size. This inconsistency may result
in potential OOB when a large number of jacks are set up via configfs,
although the max number of cables (the loop count) is limited to
MAX_CABLES.
For addressing it, correct th
usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd
generic_set_cmd() and generic_get_cmd() use the low nibble of
ctrl->bRequest as an index into con->data[]:
u8 cmd = (ctrl->bRequest & 0x0F); /* 0 .. 15 */
...
con->data[cmd] = value; /* OOB when cmd >= 5 */
struct usb_audio_control (include/linux/usb/audio.h) declares data as
a 5-element array, so indices 5 through 15 write (or read) up to 44
bytes past the end of the array on the heap.
A malicious USB host can craft a class-specific SET_CUR / GET_CUR
request with an arbi
usb: typec: anx7411 - stop the IRQ before destroying the workqueue
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: anx7411 - stop the IRQ before destroying the workqueue
The IRQ is devm-managed, so it can still queue plat->work while
remove() is tearing the queue down. Disable it first.
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: fix IRQ storm on invalid event buffer count
When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the
event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check
that event count does not exceed event buffer length") returns IRQ_NONE
without writing back GEVNTCOUNT. Since the DWC3 interrupt is
level-triggered, the uncleared IRQ source keeps the line asserted,
causing a tight IRQ storm that accumulates 99,900 unhandled interrupts
and triggers spurious.c:184 BUG -> kernel panic.
The resulting call stack:
__report_bad_irq+0xac/0xc8
note