From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60541357CF4 for ; Sun, 26 Jul 2026 13:26:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785072420; cv=none; b=uSFab81OM5IPg5QnLK+0wIOozpu+eOLxAP/t2bdcs6tsEoZvH6oRCBNErwdw6aG/skp4dSUiarFeg9mhlHAw4Rc/JALx06AyFteeNcIta9Knf769nj4BdUbTZtfS5YRTfzxfDa3R8urMwah2R5TfoC+pi5LnJgWecKffi8VYZIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785072420; c=relaxed/simple; bh=WdwBdT4UVjQH5xheJ4pUWP1kKPrpjOnQsNT94jDhUcY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RVaXqgyRu6Q9qPhUiKFmZmnrYzRyute3eVEPeqC7sKoS6hLQqUaTaOl5d4zgz7M32ddXccLGAlNe8kvomWyendIbVs47MduFdsEKESzzLkr6h8EpLOIO1HyJw9rxDI6kuZZACX6gJubrAFGbflYbDTliV+bXKlQJqUA9tuAv6Jo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=MMOSHlKu; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="MMOSHlKu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCD6F1F000E9; Sun, 26 Jul 2026 13:26:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785072417; bh=AriE2Taue/hP3sGvxJZ8s/7Mx9pRc8hHlp+q4pibLZ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=MMOSHlKup4IPdN4LQJ7Px3+nSKY9GmDJSfyieucf3lqBxDTAfmley5G5UXPMeOLoh 3YsRabDXiMwUZkpzhwgHSJMlQJN6DSY694/M9yRsXkA5lR56sGmm9/f3MaxCsoimDp YHfE6LlhiUImigsUPlFpOfXhnUREEM1YDKcHybdE= Date: Sun, 26 Jul 2026 15:26:45 +0200 From: Greg KH To: Wang Zihan Cc: jirislaby@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vt: add mode validation in vt_setactivate Message-ID: <2026072618-scrounger-eskimo-3a01@gregkh> References: 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 Sun, May 03, 2026 at 03:46:15AM +0800, Wang Zihan wrote: > The vt_setactivate() function accepts any mode value without validation, > while VT_SETMODE correctly rejects invalid values (only VT_AUTO and > VT_PROCESS are valid). > > This allows users to set invalid mode values (e.g., 0xFF) which bypasses > VT_PROCESS signal handling and causes undefined VT switching behavior. > > Fix this by adding the same validation as VT_SETMODE. > > Signed-off-by: Wang Zihan > --- > drivers/tty/vt/vt_ioctl.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c > index 28993a3d0acb..b8787283a0fa 100644 > --- a/drivers/tty/vt/vt_ioctl.c > +++ b/drivers/tty/vt/vt_ioctl.c > @@ -596,6 +596,8 @@ static int vt_setactivate(struct vt_setactivate __user *sa) > return -EFAULT; > if (vsa.console == 0 || vsa.console > MAX_NR_CONSOLES) > return -ENXIO; > + if (vsa.mode.mode != VT_AUTO && vsa.mode.mode != VT_PROCESS) > + return -EINVAL; Are you sure this isn't intentional? How was this tested? If an "invalid" mode is set, what happens? thanks, greg k-h