Re: [PATCH v2 2/4] serial: core: clear freed pointers on uart_register_driver() failure

[Greg Kroah-Hartman]

On Mon, Jul 20, 2026 at 12:10:12AM +0200, Karl Mehltretter wrote:
> uart_register_driver() leaves freed pointers behind on failure. If
> tty_alloc_driver() fails, it frees drv->state without clearing it. If
> tty_register_driver() fails, it also drops the tty driver reference
> without clearing drv->tty_driver.
> 
> Several drivers register the uart_driver lazily and use drv->state as
> an "already registered" sentinel. After a failed registration, the
> next probe sees the stale pointer, skips re-registration and calls
> uart_add_one_port() with freed state.
> 
> The resulting unwind can call uart_unregister_driver() with a NULL or
> dangling drv->tty_driver and oops in tty_unregister_driver():
> 
>   Unhandled fault: page domain fault (0x01b) at 0x00000018
>   PC is at tty_unregister_driver+0x10/0x68
>   LR is at uart_unregister_driver+0x1c/0x60
> 
> Reproduced with failslab fail-nth injection on qemu's raspi1ap board:
> fail the tty_alloc_driver() allocation during a sysfs bind of the
> PL011 port, then bind again in the same boot.
> 
> Clear drv->state after freeing the state array and clear
> drv->tty_driver after dropping the tty driver reference, as
> uart_unregister_driver() already does.
> 
> The tty_register_driver() failure case predates Git history. The
> tty_alloc_driver() failure case was introduced by commit 9e845abfc8a8
> ("serial: fix NULL pointer dereference"), which made that error path
> return cleanly instead of crashing in put_tty_driver(NULL).
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Fixes: 9e845abfc8a8 ("serial: fix NULL pointer dereference")
> Cc: stable@xxxxxxxxxxxxxxx

Same comment here, this can't ever be hit by a "normal" user, right?

thanks,

greg k-h