| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some small tty/serial driver fixes for 7.3-rc6. Nothing major
here, just lots of small fixes for reported issues, some of them very
long-standing:
- tty hangup fixes that have been there since the BKL days and kept
tripping people up over time.
- vt selection bugfix
- other vt bugfixes (memory leaks and screen update fixes)
- n_gsm bugfix
- qcom-geni serial driver bugfix
- 8250 serial driver bugfixes
- other tiny serial driver fixes
All of these have been in linux-next, the last few only a few days but
testing here seems solid (this pull request was generated on that
tree)"
* tag 'tty-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (37 commits)
tty: add missing driver flag kernel-doc colon
vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection()
vt: skip screen update for DEC alignment test on backgroup consoles
vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF
serial: sc16is7xx: reduce TX refill rate with half-FIFO trigger
serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL
serial: tegra: don't clear the Tx FIFO on an Rx-only reset
serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around
tty: fix saved termios reset race
tty: serial: mpc52xx_uart: move static declarations up.
tty: serial: max3100: shut down timer before freeing port
tty: add break_wait kernel-doc
serial: qcom-geni: keep registered console runtime active
serial: qcom-geni: Fix unbalanced runtime PM resume for no_console_suspend
serial: qcom-geni: avoid unused-function warning
tty: serial: qcom_geni_serial: Keep console RX functional after deep idle
soc: qcom: geni-se: Correct QUP Core ICC vote constants
serial: 8250_bcm7271: fix use-after-free in brcmuart_remove()
serial: vt8500: Fix clock reference leak in vt8500_serial_probe()
kgdboc: Fix tty driver reference leak in configure_kgdboc()
...
|
|
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 reset on registration and only set it for drivers that
make sure that the minor number is no longer in use.
Fixes: 93857edd9829 ("tty: reset termios state on device registration")
Reported-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Link: https://lore.kernel.org/20260926184154.3017929-1-nicoyip.dev@gmail.com
Cc: stable@kernel.org # 4.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260930131845.1809256-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Avoid a compilation error so that they're not used before being
declared.
Fixes: 4d105880666a ("tty: serial: mpc52xx_uart: add bounds check for psc_num array index")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609260356.tJWbd1WU-lkp@intel.com/
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260927203501.14105-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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_interrupt+0x340/0x468
handle_irq_event+0xac/0xc0
handle_fasteoi_irq+0x120/0x228
gic_handle_irq+0x68/0x108
...
kernel BUG at kernel/irq/spurious.c:184
To reproduce, write a bogus value exceeding the event buffer length
directly to the GEVNTCOUNT register:
devmem <DWC3_BASE + 0xc40c> 4 0x1004
Write the bogus count back to GEVNTCOUNT to clear the IRQ source,
consistent with the stale event clearing pattern in
dwc3_event_buffers_setup(), and schedule error recovery to
reinitialize the controller.
Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length")
Cc: stable <stable@kernel.org>
Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Jiazi Liu <jiazi.liu1984@gmail.com>
Link: https://patch.msgid.link/20260915110637.17658-1-jiazi.liu1984@gmail.com
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit a107edec57659c5a1a2f016311b944af58c904c9.
It was incorrectly applied, and was 2 versions old. The "correct" one
will be added instead afterward...
Cc: stable <stable@kernel.org>
Cc: Jiazi Liu <jiazi.liu1984@gmail.com>
Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Fixes: a107edec5765 ("usb: dwc3: gadget: fix IRQ storm on invalid event buffer count")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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_irq()
emulation routine returns -- they aren't supposed to be in the middle
of a completion callback. If this happens it can lead to a gadget
driver's unbind routine running before all outstanding request
completions have finished, maybe even allowing the gadget driver's
module to be unloaded while a completion handler is still running.
Fix the oversight by incrementing the callback_usage value across
request completion callbacks.
Link: https://lore.kernel.org/linux-usb/7a87e293-633c-4100-aa8d-91560ba5e5c5@rowland.harvard.edu/
Fixes: 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change")
Tested-by: Minseo Kim <neck3922@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Link: https://patch.msgid.link/f23b9e1a-f110-441a-a1d8-95f442ec09d5@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
typec_port_match() adds a component match for the USB4 port whenever a
USB 3.x port that shares the _PLD with the Type-C connector has the
"usb4-host-interface" property, regardless of whether a USB4 port can
ever be registered for it. The component framework binds the aggregate
device only once every match has found its component, so if the USB4
port never shows up, the USB 2.0 and USB 3.x ports are not linked to the
connector either: the "connector" symlinks are never created and USB
devices enumerated on those ports are never linked with the Type-C
partner.
This happens in at least two cases:
1. CONFIG_USB4 is not reachable from the Type-C core, i.e. CONFIG_USB4=n,
or CONFIG_USB4=m with CONFIG_TYPEC=y as in the x86_64 gki_defconfig.
usb4_usb3_port_match() is then a stub that always returns false.
2. The firmware references a USB4 host interface that is disabled. For
example, on Intel Alder Lake-N (ChromeOS Nissa) the TCSS xHCI USB3
ports (SS01-SS04) reference TDM0/TDM1, whose _STA returns 0 because
the SoC has no integrated Thunderbolt/USB4 and the DMA controllers
are disabled in TCSS DEVEN. No PCI device is enumerated for them.
Only add the USB4 component match if CONFIG_USB4 is reachable and the
referenced host interface is available and has been enumerated as a
device. The latter mirrors the check in usb_acpi_add_usb4_devlink(), see
commit 623dae3e7084 ("usb: acpi: fix boot hang due to early incorrect
'tunneled' USB3 device links").
Fixes: 4fd7a1f0f7f2 ("usb: typec: Connect Type-C port with associated USB4 port")
Cc: stable <stable@kernel.org>
Signed-off-by: Marek Maslanka <mmaslanka@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260925131650.3777399-1-mmaslanka@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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.
logs:
Call trace:
cdns3_pci_probe+0xa4/0x300
local_pci_probe+0x44/0xa8
pci_call_probe+0x54/0x158
pci_device_probe+0x84/0x100
really_probe+0x184/0x3d0
__driver_probe_device+0x80/0x178
driver_probe_device+0x44/0xe8
__driver_attach+0xec/0x1f8
bus_for_each_dev+0x7c/0xe0
driver_attach+0x28/0x38
bus_add_driver+0x110/0x238
driver_register+0x64/0x128
__pci_register_driver+0x50/0x60
cdns3_pci_driver_init+0x28/0x38
do_one_initcall+0x5c/0x280
do_initcalls+0x104/0x1d8
kernel_init_freeable+0x140/0x218
kernel_init+0x28/0x1f8
ret_from_fork+0x10/0x20
Return -EPROBE_DEFER in this case so that probing is retried after
the first function has completed its probe.
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Jie Deng <dengjie03@kylinos.cn>
Acked-by: Peter Chen <peter.chen@kernel.org>
Link: https://patch.msgid.link/20260810023626.70669-1-dengjie03@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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_interrupt+0x340/0x468
handle_irq_event+0xac/0xc0
handle_fasteoi_irq+0x120/0x228
gic_handle_irq+0x68/0x108
...
kernel BUG at kernel/irq/spurious.c:184
To reproduce, write a bogus value exceeding the event buffer length
directly to the GEVNTCOUNT register:
devmem <DWC3_BASE + 0xc40c> 4 0x1004
Write the bogus count back to GEVNTCOUNT to clear the IRQ source,
consistent with the stale event clearing pattern in
dwc3_event_buffers_setup(), and schedule error recovery to
reinitialize the controller.
Fixes: 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length")
Cc: stable <stable@kernel.org>
Co-developed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Jiazi Liu <jiazi.liu1984@gmail.com>
Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://patch.msgid.link/20260907073756.22329-1-jiazi.liu1984@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
ucsi_find_fwnode() currently maps UCSI connectors to Device tree
connector nodes based on the order in which connector child nodes
are described in DT.
This can fail because the ordering of child nodes isn't guaranteed
in Device-tree. For example, DTB may contain connector@1 before
connector@0, causing connector numbers to be associated with the wrong
fwnode. As a result, role switch and Type-C notifications can be
delivered to the wrong remote endpoints.
Fix this by using the "reg" property of each connector to match
its corresponding fwnode. While at it, if the reg property isn't
present, then fall back to the old method.
Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Cc: stable <stable@kernel.org>
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260916042808.2879079-1-prashanth.k@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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 arbitrary bRequest value, triggering the out-of-bounds
access from an IRQ completion handler with no further preconditions.
Add an ARRAY_SIZE() guard to both functions.
Fixes: c47d7b09891a ("USB: audio: add USB audio class definitions")
Cc: stable <stable@kernel.org>
Reviewed-by: Weibin Liu <liuwb@xiaopeng.com>
Signed-off-by: Liu Chao <liuc63@xiaopeng.com>
Reviewed-by: Ivy Lopez <skunkolee@gmail.com>
Link: https://patch.msgid.link/20260921072551.3708191-1-liuc63@xiaopeng.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
