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
usb: gadget: aspeed-vhub: cancel wake work on device removal
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: aspeed-vhub: cancel wake work on device removal
wake_work is armed from the gadget .wakeup callback to resume suspended
downstream ports, and it is never cancelled in ast_vhub_remove(), so a
work item queued before or during removal can run after devm has freed
vhub and its ports, a use-after-free.
Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes
no lock and the unbind path never clears wakeup_en, so a remote-wakeup
request in flight on another CPU can re-arm the work after the cancel
and before vhub is freed.
ast_vhub_del_dev() already
USB: gadget: dummy-hcd: Fix wait for outstanding request completions
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: dummy-hcd: Fix wait for outstanding request completions
The dummy-hcd driver emulates synchronize_irq() by waiting until its
private callback_usage counter drops to 0 (with the private lock not
held). This counter is incremented whenever a gadget driver callback
occurs (which requires the private lock to be dropped), but not when a
request completion handler is called.
This is an oversight. Request completion is triggered by timer
interrupts (emulating device IRQs in a real UDC), and the interrupt
handlers are supposed to have completed when the synchronize_
usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC
When user space sets up FunctionFS with only full-speed descriptors
(e.g., flags = FUNCTIONFS_HAS_FS_DESC) and the gadget operates at a
higher speed (such as USB_SPEED_HIGH or USB_SPEED_SUPER),
config_ep_by_speed() detects that the function lacks descriptors for
the current speed, logs a warning, and falls back to full-speed
descriptors. The endpoint is then successfully enabled via
usb_ep_enable(), and epfile->ep becomes valid.
However, when user space subsequently issues the FUNCTIONFS_ENDPOINT_D
usb: core: clear both ep_in and ep_out for non-ep0 control endpoints
In the Linux kernel, the following vulnerability has been resolved:
usb: core: clear both ep_in and ep_out for non-ep0 control endpoints
In usb_enable_endpoint(), non-zero control endpoints (where
usb_endpoint_xfer_control(&ep->desc) is true) populate both
dev->ep_in[epnum] and dev->ep_out[epnum] with the same struct
usb_host_endpoint pointer.
However, usb_disable_endpoint() only clears either dev->ep_out[epnum] or
dev->ep_in[epnum] depending on the direction bit of epaddr when
reset_hardware is set, leaving the opposite direction's array slot
pointing to the disabled/freed endpoint.
Clear both dev->ep_out[epnum] and dev->ep_in[epnum] whe
USB: dwc2: shut down wakeup timer before freeing HCD state
In the Linux kernel, the following vulnerability has been resolved:
USB: dwc2: shut down wakeup timer before freeing HCD state
dwc2_wakeup_detected() accesses the DWC2 host state and can rearm the
wakeup timer. dwc2_hcd_free() currently deletes the timer only after
freeing host-owned state, and timer_delete() does not synchronize a
callback or prevent it from being queued again.
Stop and shut down the timer in dwc2_hcd_release(), before the HCD
resources are freed. This covers both the HCD initialization error path
and normal HCD removal.
Media · CVSS 5.1EPSS 0,17%Sin corrección publicada
usb: typec: tcpm: recover after failure to start the frs ams
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: recover after failure to start the frs ams
Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by
initiating error recovery on it.
This helps in cases where some cables (incorrectly) signal an FRS to
an FRS capable port during disconnection. The TCPC autonomously starts
sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is
left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok
is 0 as CC is open due to the cable disconnect). This is because the
code sets the state to INVALID_STATE without resetting the port
Media · CVSS 4.3EPSS 0,17%Sin corrección publicada
usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect()
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect()
tps6598x_connect() passes a stack-allocated typec_partner_desc to
typec_register_partner() after initializing only usb_pd, accessory and
identity.
typec_register_partner() copies attach and deattach from the descriptor
into the partner. With those fields left unset, garbage function pointers
may be stored and later invoked from typec_partner_link_device() when a USB
device is linked to the port. Uninitialized pd_revision and usb_capability
similarly leak stack data through partner sysfs.
Zero-ini
usb: cdns3: fix use-after-free in cdns3_gadget_exit()
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix use-after-free in cdns3_gadget_exit()
cdns3_gadget_start() arms two works on system_freezable_wq:
pending_status_wq for the deferred ep0 status stage and aligned_buf_wq
for realigned request buffers. Both handlers use the cdns3_device the
works are embedded in, and cdns3_pending_setup_status_handler() also
calls the ep0 request completion.
cdns3_gadget_exit() does not wait for these works. It frees all
endpoints and aligned buffers and drops the last reference to the
gadget device, which frees priv_dev, so a work queued before the exit
can run after the fre
usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe
The Cadence USBSS controller is a two-function PCI device. The first
probed function allocates the driver data and stores it with
pci_set_drvdata(), while the second function reuses it via
pci_get_drvdata() when pci_is_enabled() reports that the first
function has already been probed.
When the second function is probed while the first one has been
enabled but has not yet set its driver data, pci_get_drvdata()
returns NULL, and the subsequent wrap->devfn assignment dereferences
a NULL pointer and crashes the kernel
tty: vcc: zero-initialize control packet in vcc_send_ctl()
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: zero-initialize control packet in vcc_send_ctl()
The stack-allocated struct vio_vcc pkt was partially initialized,
leaving the tag.stype_env field uninitialized before being sent via
ldc_write(), potentially leaking kernel stack data to the LDC peer.
tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup
vcc_cleanup() sets port->tty to NULL without holding port->lock, racing
with vcc_event() LDC callbacks that read port->tty under port->lock and
then use tty->port. This can cause a use-after-free when the callback
dereferences tty->port after cleanup has already destroyed and freed it.
Media · CVSS 5.6EPSS 0,17%Sin corrección publicada
tty: tty_port: restore TTY_IO_ERROR on activation failure
In the Linux kernel, the following vulnerability has been resolved:
tty: tty_port: restore TTY_IO_ERROR on activation failure
Make sure to restore the TTY_IO_ERROR flag if activation fails to
prevent I/O attempts on a port that is gone or powered down.
This specifically avoids issues like kernel panic due to unclocked
accesses or NULL-pointer dereferences when accessing powered down or
deregistered ports when a TTY ioctl races with hangup and open.
Note that the flag is set again in tty_port_close() but not restoring it
on activation failure leaves a window where drivers fail to handle the
ioctl-hangup race.
In the Linux kernel, the following vulnerability has been resolved:
tty: port: fix tty_port_tty_vhangup() race
Drivers rely on tty_port_tty_vhangup() to synchronously hang up their
ports before tearing down resources as part of deregistration (e.g. on
physical disconnect).
If tty_port_tty_vhangup() races with another hangup it may however
return before the port has been shut down. This is in turn can lead to
use-after-free and NULL-pointer dereferences in racing ioctls (including
a synchronous hangup) and in processing of racing asynchronous hangups
(carrier loss).
Add the missing serialisation to tty_port_tty_vhangup() and
tty_port_hangu
In the Linux kernel, the following vulnerability has been resolved:
tty: abort break signalling on hangup
The break ioctls can race with hangup and end up calling into a tty
driver for a device that is already gone or powered down.
Drivers must handle this race, but TCSBRK and TCSBRKP should still be
aborted to avoid calling back into the driver after a user-controlled
timeout (possibly even after the tty has been reopened).
Note that drivers should disable any break state on shutdown so just
return on hangup (calling break_ctl() again is racy and will most likely
fail for drivers handling the race).
Media · CVSS 5.4EPSS 0,17%Sin corrección publicada
tty: fix saved termios reset race
In the Linux kernel, the following vulnerability has been resolved:
tty: fix saved termios reset race
Resetting saved termios state on device registration is needed where a
minor number can be reused for an entirely different device and where
the old settings may prevent the port from even being opened (e.g. when
CLOCAL is not set).
Not all TTY drivers guarantee that the minor number is no longer in use
when registering devices however, something which can lead to a
use-after-free when closing a TTY (and saving its termios) races with
re-registration.
Add a new TTY_DRIVER_RESET_SAVED_TERMIOS flag to request that any saved
termios state is
tty: serial: max3100: shut down timer before freeing port
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: max3100: shut down timer before freeing port
max3100_shutdown() stops the polling timer but returns early during
system suspend. If the SPI device is unbound before resume, the serial
core does not call max3100_shutdown() again, so max3100_remove() frees
the port while the timer remains armed. max3100_timeout() may then
access the freed port and re-arm the timer.
Add final timer teardown to max3100_remove() and use
timer_shutdown_sync() to prevent a racing callback from re-arming it.
Also free the IRQ and destroy the workqueue there before freeing the
port. Ke
serial: 8250_bcm7271: fix use-after-free in brcmuart_remove()
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_bcm7271: fix use-after-free in brcmuart_remove()
brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout
quirk of the 8250 core when hardware flow control is enabled; the timer
callback brcmuart_hrtimer_func() dereferences priv.
brcmuart_remove() cancels the hrtimer before it unregisters the port, so
a receive-timeout interrupt that arrives in between re-arms the timer.
After devm frees priv, the callback runs on freed memory.
Unregister the port before cancelling the hrtimer.
serial8250_unregister_port() shuts the port down and frees its IRQ,
Media · CVSS 6.8EPSS 0,17%Sin corrección publicada
arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems
When system_supports_sme() is true but system_supports_sve() is false,
restoring a specifically crafted SVE signal context can result in the
task erroneously having non-streaming SVE state. Subsequent attempts to
manipulate the task's FPSIMD/SVE/SME state can result in a variety of
problems, including fatal EL1 UNDEFs.
In such configurations, the kernel always creates an SVE signal context
when delivering a signal, and this can only be in one of two states:
(1) SVE_SIG_FLAG_SM is set, and an SVE pa
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Serialize compat port-info ioctls
The native sequencer ioctl path serializes handler calls with
client->ioctl_mutex, but the translated port-info compat path invokes the
same handlers through snd_seq_kernel_client_ctl() without taking that
mutex.
This lets concurrent compat CREATE_PORT requests pass the port-count
check before any request reaches the serialized insertion. The computed
integer port index can then exceed the address field range and wrap to an
existing index. Subsequent subscriber teardown can resolve the duplicate
address to the wrong port and acc