mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v3 0/2] usb: gadget: u_serial: fix gs_port use-after-free on open/unbind race
@ 2026-11-09 14:11 Varun Singh
  2026-11-09 14:11 ` [PATCH v3 1/2] usb: gadget: u_serial: serialise line setup against line teardown Varun Singh
  2026-11-09 14:11 ` [PATCH v3 2/2] usb: gadget: u_serial: fix gs_port use-after-free on open/unbind race Varun Singh
  0 siblings, 2 replies; 3+ messages in thread
From: Varun Singh @ 2026-11-09 14:11 UTC (permalink / raw)
  To: nkapron, gregkh
  Cc: linux-usb, linux-kernel, bigeasy, syzbot+39a2135de1558208d3b3,
	Varun Singh

2/2 fixes the use-after-free reported by syzbot in check_tty_count(). It
is based on v2, with the device unregistration change moved into 1/2.

1/2 is new. While reviewing v2 I noticed that ports[n].lock protected the
ports[n].port slot but not the matching tty device registration, letting
concurrent function creation and removal race so that creation fails with
-EEXIST. That is independent of the reported use-after-free, but 2/2
relies on the slot and the device changing together, so it goes first.

v2 -> v3:
 - new 1/2: hold ports[n].lock across slot assignment and device
   registration, and across slot clearing and device unregistration
 - 2/2: unregister-before-free moved into 1/2; otherwise unchanged

v1 -> v2:
 - look the port up in .install and hold a tty_port reference for the
   lifetime of the tty, instead of clearing tty->driver_data on close
 - drop the close_wait handshake: with a correct port count it blocks
   rmdir until userspace closes /dev/ttyGS*, seen as a hung task
 - hang up any tty still installed on a freed line, and recheck in
   gs_open() that tty->driver_data matches the registered port

Testing, in QEMU against a configfs mkdir/rmdir and open() race
reproducer, A/B against unmodified master each time:
 - clean under KASAN and, separately, under lockdep (PROVE_LOCKING,
   DEBUG_ATOMIC_SLEEP, DETECT_HUNG_TASK); kmemleak reported no leaks
 - slab fault injection exercised 1/2's registration-failure rollback
   107 times, after which the line was still allocatable and openable
 - 1/2 was built and booted on its own, to check bisectability
 - the series passed #syz test on 2026-11-08 against syzbot's own
   reproducer, which covers the acm path the local one does not:
   "testing succeeded, no crash reproduced"

Not addressed here: gserial_alloc_line() re-reads ports[0].port after the
line's lock has been dropped and passes it to gs_console_init(), which has
no NULL check, so a concurrent gserial_free_line(0) can leave it NULL.
This predates the series. I have left it out rather than pull
register_console() under ports[n].lock without investigating that further,
and can send a separate patch for it.

Link: https://lore.kernel.org/all/20261102193436.6044-1-varun.singh10011@gmail.com/ [v2]

Varun Singh (2):
  usb: gadget: u_serial: serialise line setup against line teardown
  usb: gadget: u_serial: fix gs_port use-after-free on open/unbind race

 drivers/usb/gadget/function/u_serial.c | 132 ++++++++++++++++---------
 1 file changed, 85 insertions(+), 47 deletions(-)

-- 
2.34.1


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-11-09 14:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-09 14:11 [PATCH v3 0/2] usb: gadget: u_serial: fix gs_port use-after-free on open/unbind race Varun Singh
2026-11-09 14:11 ` [PATCH v3 1/2] usb: gadget: u_serial: serialise line setup against line teardown Varun Singh
2026-11-09 14:11 ` [PATCH v3 2/2] usb: gadget: u_serial: fix gs_port use-after-free on open/unbind race Varun Singh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®