Re: [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code

[John Ogness]

On 2026-06-30, sashiko-bot@xxxxxxxxxx wrote:
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>
> [ ... ]
>
>> @@ -3211,6 +3208,8 @@ static bool console_emit_next_record(struct console *con, bool *handover, int co
>>  		*handover = console_lock_spinning_disable_and_check(cookie);
>>  		printk_safe_exit_irqrestore(flags);
>>  	}
>> +	printk_delay(true);
>> +
>
> [Severity: Critical]
> This isn't a bug introduced by this patch, but does the expanded delay
> create a use-after-free window for the con pointer in console_flush_all()?
>
> In console_emit_next_record(), if a lock handover occurs,
> console_lock_spinning_disable_and_check() releases the SRCU read lock.
>
> This patch inserts printk_delay(true) immediately after this lock release,
> adding a multi-millisecond busy-wait delay.
>
> During this expanded window, another CPU can unregister and free the console
> because the SRCU lock is no longer held.
>
> When console_emit_next_record() returns to console_flush_all(), it
> unconditionally dereferences con->seq before checking if a handover occurred:
>
> 		if (!console_emit_next_record(con, &handover, cookie))
> 			continue;
> 		printk_seq = con->seq;
>
> Could this massive delay guarantee a use-after-free if a console is
> unregistered under contention?

This is a legitimate bug report (even without this series). I will post
a patch for this.

John Ogness