From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D897135A3A4 for ; Thu, 4 Jun 2026 10:22:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780568523; cv=none; b=e6bkZy+pGYUEBSpnIWqY4bnQXtz/qfWTuqvNGW5X4nNP0t3EvMp7dTEE7VlKiCVOl+CtcT7f+0fJXmqnNLP8KSjD/0IXNWJQ/humJZIiG7ktWX5qvXLrVO8P3ekCNa8RF21WWYV+YLEs2kJbGtmZsZE8EK29nojKelFVHozI8CI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780568523; c=relaxed/simple; bh=SdpZrDZ9PNZ0XAOPyvo4vI9hR3lrHF37OTotrxDYbIE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mrudfPjHbKUsU0Jlqtkj9ot/68W6leIRlKT5ttqj1jvf/D+YIsW/NR8U/c4GLXgrmqgJV4MWPA9kLIZR2G7bUOaDqCyORumCzQ3tPlNiuStZ9UvRUCtMDtFWzdc1YkaCkqH4BvesIg1q44jXTShFwGnDg4pVSSX1Y637pYegW30= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=gzBSW3No; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="gzBSW3No" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-45eec22fab7so268542f8f.3 for ; Thu, 04 Jun 2026 03:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780568520; x=1781173320; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SOpcqmGalyvsNMX/H+a8nTgozaeSYqN4p+pRNXwbav4=; b=gzBSW3NoxHBKJRkbG/tLH2s3zeNfA63XNcw8srNnVsAQ9KRZAdT9mOwoXRLchAmHQJ wxoJKLYvccC7UE8OyaS1OI4xnxyNIrmY7oqQd2jv3SjlrWa7Dubx44OwXw5Z5l9egOs0 5xlmhHMUic1yFTsKnSpHSom1tWDv3zFjZjWHisryDO0vPc25CghkUPlhxqGB1k4Pftqc Qf1opHTc/+RUSNZEW+1+FKQvnLMpbY2XgTkVYNAbeVP57hQ4NdLS0YQOH/HheIE8eSDU Tqb/wLIlRLEX/K50MrBsWfL4dY9z07Eo6xRxMcQl1NHS4eavx101ul2mv4EylKNej54K AgBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780568520; x=1781173320; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SOpcqmGalyvsNMX/H+a8nTgozaeSYqN4p+pRNXwbav4=; b=ouYPzbbVavappDoL6bvg8L0nCVfriKV4RZU6Zm54h5nJcX6nHtIVJuMPg036UlCAON 2/ZAoH1v8QXYMM+ZSFsGU+634ocUTJ49xi4RBRDyHaL7jmbVsivBNb9e8Q4OL5SibgN7 DM9Z94wK7n4QVJheKr8TOwAnw8BuN9LoKus8G2pynMVfZ9RWykQIn/Ax0SWt8HGPp1Yu Oyu9NV+nxDEhLiquujAwevSr/fAGpN/lTDUdEXX9q0xoXWnUI0egWSVfNe+79SqVk/dJ MaAowG8Zxyjv4o8/4wBlnggi7257fcJFH0DEo+e/LxiCnQtE3VhvCoVIpZ0BS6MACJjZ lctA== X-Forwarded-Encrypted: i=1; AFNElJ/2o5AI4O+VoGnT84CU/FB8PFCYtxVQTz2dwYlA6L+logUhyknhySQPtvfSqgWPGdCshLHYYmQDcnUHz5c=@vger.kernel.org X-Gm-Message-State: AOJu0YxXTrYR1jCqEUsxAobLzH30fjB70azIuikPPhS3329zpETpDF7x SjEuwh/YBT1/sz8vqOXeVOY8WrR4HGzbDwzKqw4a1ObcL+x4Pt70Fp1V6LrECm477xY= X-Gm-Gg: Acq92OErixEhAQAfPOj+z5OX2Xtm7fULtSRCn1V32SVkDF/FHVmwznnlfifDygRSdxm pTBlW/89pqtzyER/pfT9PpJZP4XLB0JtGD+MjApwrhaYUR8Xmz2LMEio55DU9gR9Q4eKdWDa/sR nQ03z/fUZJQeYKlAGazrLa94pvDn6IX3rlllBveGRO59P3ywe/zCCV78hCU2fJzypZaa++WTU16 X2If+JUOVQeXuYQaM7SGe7kBtY0NvOE+vXvK5RI6aK92fK4mz8i985aTiYAhvAun/NRrtPG3A7O ipbfs8wimjxoREnvYZrnnL1Z+HqOMZouwUDIBbgAQNlGx9vwwuvpx0Wvxt7O1CtOQKbo6VoHbV8 Z70bTtBlhdp7fmkq9nEkzzD+DuYiVzNafrpTlX2Rgm1AFJRiKxy1Dad2IZGs7mIaSGy7BUYODcz ommR52fMo942o+GnAx/XoIEz2lXNo0fJM5LeWP X-Received: by 2002:a05:600c:45c3:b0:490:bbc4:76a6 with SMTP id 5b1f17b1804b1-490bbc47820mr60825565e9.21.1780568520267; Thu, 04 Jun 2026 03:22:00 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b7a273e3sm97307375e9.0.2026.06.04.03.21.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 03:21:59 -0700 (PDT) Date: Thu, 4 Jun 2026 12:21:57 +0200 From: Petr Mladek To: Naveen Kumar Chaudhary Cc: Steven Rostedt , John Ogness , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH] printk: fix out-of-bounds access in try_enable_preferred_console() Message-ID: References: <7sq4tr2nmlz32tvkf6vpsghv6exvqfghsrlvywjcqihzsqqbf7@bspclmti5xg4> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu 2026-06-04 12:18:27, Petr Mladek wrote: > (Once again with corrected LKML address. I am sorry for noice.) > > Adding other printk subsystem reviewers into Cc. > > There is get_maintainer.pl script for this purpose. For example: > > $> ./scripts/get_maintainer.pl kernel/printk/printk.c > Petr Mladek (maintainer:PRINTK) > Steven Rostedt (reviewer:PRINTK) > John Ogness (reviewer:PRINTK) > Sergey Senozhatsky (reviewer:PRINTK) > linux-kernel@vger.kernel.org (open list) > > On Sat 2026-05-30 10:18:24, Naveen Kumar Chaudhary wrote: > > When all MAX_CMDLINECONSOLES (8) slots in console_cmdline[] are occupied > > and none match the newly registered console, the for loop exits with > > i == MAX_CMDLINECONSOLES and c pointing past the end of the array. The > > subsequent access to c->user_specified is then an out-of-bounds read. > > Great catch! > > > This can occur when a self-enabling console (one with CON_ENABLED already > > set), such as netconsole or pstore, calls register_console() on a system > > where the console_cmdline[] array has been filled by a combination of > > command-line console= parameters, ACPI SPCR, device tree stdout-path, > > and/or arch-specific add_preferred_console() calls. > > > > Add a bounds check to ensure c is only dereferenced when the loop exited > > due to finding an empty slot (i.e., c still points within the array). > > Also add parentheses around the bitwise-AND to silence compiler warnings > > about its use in a boolean context. > > But the fix is is not correct, see below. > > > --- a/kernel/printk/printk.c > > +++ b/kernel/printk/printk.c > > @@ -3938,7 +3938,8 @@ static int try_enable_preferred_console(struct console *newcon, > > * without matching. Accept the pre-enabled consoles only when match() > > * and setup() had a chance to be called. > > */ > > - if (newcon->flags & CON_ENABLED && c->user_specified == user_specified) > > + if (i < MAX_CMDLINECONSOLES && (newcon->flags & CON_ENABLED) && > > + c->user_specified == user_specified) > > This would prevent the out-of-bound access to c->user_specified. > > But the check of c->user_specified does _not_ make sense in the first > place. > > Background: > ----------- > > The idea was that we would allow to match a preferred console > and run newcon->setup(). By other words, this code should > be called in register_console() after > > /* See if this console matches one we selected on the command line */ > err = try_enable_preferred_console(newcon, true); > > /* If not, try to match against the platform default(s) */ > if (err == -ENOENT) > err = try_enable_preferred_console(newcon, false); > > , when try_enable_preferred_console() did not return a real error. > The real error is an error from newcon->setup(). Note that -ENOENT > is not meant as a real error here. > > Solution: > --------- > > IMHO, the right approach is to move this code out of > try_enable_preferred_console(). Like it is done in my clean up of > the registration code. I have just sent v3 earlier today, see > https://lore.kernel.org/all/20260602085312.228251-10-pmladek@suse.com/ > > That said, I think about backporting the 10th patch from the > above mentioned clean up and fixing this ASAP. Better be > safe than sorry... JFYI, the fix for this problem is the 1st patch in v4 of the above mentioned clean up, see https://lore.kernel.org/all/20260604101459.393162-2-pmladek@suse.com/ It would be great if anyone could review at least this 1st patch soon. Best Regards, Petr