From nobody Thu Apr 2 15:41:19 2026 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 0EF3234B1A2 for ; Fri, 27 Mar 2026 17:03:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630999; cv=none; b=R8v+JdAxiv/MBaIIBvqyrg084PH4x5pW/7Novw0q4kHQaDSxz5hJ9MgX0TD3aHGlXvSf5ezzxesPOaeF9+XtMwUuVm+LtbNekVj3KmnOVkz/SPTf5uFKNv4vgMl7hmwtVZmypZY+US1IK8RkfDhT+q5axHDhvq20zIfr86+GP2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630999; c=relaxed/simple; bh=XF387l1iSQ3JkQCBcOvMlB0b0a6/XXCleJmbhWho1Ik=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZPf3hjivPPm+xxEfZ29nBUK1wrgz4Szv9AIJRwlW2MK4LifZFdFXm3aiKZHq6A6IjRJdVuwoZauLEr4zcQtiSJe7ZuZhfXjeCO6Vcdgt+oCROgbCNU4PRj17n6UV4dj1QvYZvNEKsvvK3kPUCHXTVz2j1973uc3z++qjohZw4rA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S4xmMvZf; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S4xmMvZf" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-487012ce896so14662015e9.0 for ; Fri, 27 Mar 2026 10:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774630996; x=1775235796; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nGa1Fe6pEa0kmcSO0r7Ez3fp7Jynbk4KITXYq/Ow8IU=; b=S4xmMvZfaAhYK32nf8aC8DHDGCmGMc8jKvoAQ1DHZwH6rsDBlpZfMemJHAYg24LZR6 h2T83CRRdveIrK0pnsDKVlQHF64E+3uv4d9rmzMCgtuYCPlr/2QhwSuA+X7YroAyF9iq i8E//rnRn3J8Bcx81xOHZ2yGu7h4+0bZ1a6RqOBTCBH/jAjTy0cSduEaF5OKyiYfJcHP JQ/YKOaUQknaGGoACVF5UdQ9rl/0HvkqBFq5zWmPuFH3Qz5ILF4YBfJrC9fvSjELGiKh 1fDUCbraX1id9hFB/3yE4JBG9h32EyUSLBtwcf3KE0jmi35yaPFznlvmYvFCj4XDxf1Z j0mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774630996; x=1775235796; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nGa1Fe6pEa0kmcSO0r7Ez3fp7Jynbk4KITXYq/Ow8IU=; b=eVO9GSAJfnG0v+iGIxeVuMmpR3TPEqGlD02oEzxxkAsBvxL6QP7wKuNDcArgotASvR tfpS2cRDZ4TBHoyOGxSIWocDm/HThHG0xyTL2mE8Jdn3BaULtckE6N13GGkCXPIFmP/9 jOREYlghjk01hYl23MAhXsuFRAV2WacCE0zVjqgyCpv+J5GZuFQ9KqVXk6fFC7IaEStN DDGcx4J1cFO0O5UowS4RdRt3REFh9nm68uJ17S7qR0m9ND0DgSNIaXFcOihWqXbzHocA ePuC6XOFor4IJSBrF50XIfcASlSlzlukxkA74f0jIrrg1G3dIiGXH+nWlcxXC0v2EkZp XvCQ== X-Forwarded-Encrypted: i=1; AJvYcCVfqnZuYpmQrRMI6Kz40Hzr1iGK0PB9a54ZlsrHk4TBT9/7B/OlD0hpRwym14MKLJ23cL/1jF/MQJBw7Ps=@vger.kernel.org X-Gm-Message-State: AOJu0YwcOII/90Amt0kocWPkdzmwJYBwn7qkteP7VkKgVWYalc+mCYAh z4OuwJIVSzQJ4vahXTJRVaZLe0mjn0Qj2b/Kced2dFTtU7zaOUeErqLS X-Gm-Gg: ATEYQzyDejMTPr+bmseS5unPasbOqMwbG7ADBcsjkarmU2j2AAkjSGqV5pZBCWX/ERW YH0HBRnaJ4LONdsJtIzDp8W1smNm0z6dOQh8s9UVrtOXM5lgPpBjrIRwkhnXIQVUTbmjsC3WmAb RC9eJsHNbVuhzdJuN2OXP28A1jfYM3dnbNxMrPtJBDH6uQeOKd/HV275XYPEyFaU/6kdv9xbpQB LM39efo97QFB+01sEiDleFoy151+JB8Ji6AZZHpX7nAOzihiv5KbHi7MTNTyQQZb82t99peXBuA FLc/wdi+0F7IN5qHCZYvG/juwBdWNSj099NhqZ+zxx04QcprEHANLba1hClmohHg4HepYxwO1CJ ivChtIxRshr5VUV+LPBgKq7LSH/i9Vzh9naeDrxlQUDwoaX9bCs/1AKubbluWkIsPzkB/FwTnX9 NznM7NpNZoNtG8gTnHvw== X-Received: by 2002:a05:600c:1f11:b0:47d:8479:78d5 with SMTP id 5b1f17b1804b1-48727d5a31emr58021875e9.7.1774630995986; Fri, 27 Mar 2026 10:03:15 -0700 (PDT) Received: from tux ([2a00:a041:e07d:7c00:1ac0:4dff:feb8:fd3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48722c65989sm164553475e9.2.2026.03.27.10.03.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 10:03:15 -0700 (PDT) From: Liav Mordouch To: stable@vger.kernel.org Cc: gregkh@linuxfoundation.org, npitre@baylibre.com, linux-kernel@vger.kernel.org Subject: [PATCH v2] vt: discard stale unicode buffer on alt screen exit after resize Date: Fri, 27 Mar 2026 20:02:04 +0300 Message-ID: <20260327170204.29706-1-liavmordouch@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260327160050.31631-1-liavmordouch@gmail.com> References: <20260327160050.31631-1-liavmordouch@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When enter_alt_screen() saves vc_uni_lines into vc_saved_uni_lines and sets vc_uni_lines to NULL, a subsequent console resize via vc_do_resize() skips reallocating the unicode buffer because vc_uni_lines is NULL. However, vc_saved_uni_lines still points to the old buffer allocated for the original dimensions. When leave_alt_screen() later restores vc_saved_uni_lines, the buffer dimensions no longer match vc_rows/vc_cols. Any operation that iterates over the unicode buffer using the current dimensions (e.g. csi_J clearing the screen) will access memory out of bounds, causing a kernel oops: BUG: unable to handle page fault for address: 0x0000002000000020 RIP: 0010:csi_J+0x133/0x2d0 The faulting address 0x0000002000000020 is two adjacent u32 space characters (0x20) interpreted as a pointer, read from the row data area past the end of the 25-entry pointer array in a buffer allocated for 80x25 but accessed with 240x67 dimensions. Fix this by checking whether the console dimensions changed while in the alternate screen. If they did, free the stale saved buffer instead of restoring it. The unicode screen will be lazily rebuilt via vc_uniscr_check() when next needed. Fixes: 5eb608319bb5 ("vt: save/restore unicode screen buffer for alternate = screen") Cc: stable@vger.kernel.org Tested-by: Liav Mordouch Signed-off-by: Liav Mordouch Reviewed-by: Nicolas Pitre --- v1 -> v2: Reformatted as a proper patch with commit message, Fixes tag, and Signed-off-by. v1 was sent as an inline analysis + diff. Note: writing of this patch and analysis was assisted by AI for grammar and flow. Apologies in advance if anything reads off. drivers/tty/vt/vt.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -1907,6 +1907,7 @@ unsigned int rows =3D min(vc->vc_saved_rows, vc->vc_rows); unsigned int cols =3D min(vc->vc_saved_cols, vc->vc_cols); u16 *src, *dest; + bool uni_lines_stale; =20 if (vc->vc_saved_screen =3D=3D NULL) return; /* Not inside an alt-screen */ @@ -1915,7 +1916,18 @@ dest =3D ((u16 *)vc->vc_origin) + r * vc->vc_cols; memcpy(dest, src, 2 * cols); } - vc_uniscr_set(vc, vc->vc_saved_uni_lines); + /* + * If the console was resized while in the alternate screen, + * vc_saved_uni_lines was allocated for the old dimensions. + * Restoring it would cause out-of-bounds accesses. Discard it + * and let the unicode screen be lazily rebuilt. + */ + uni_lines_stale =3D vc->vc_saved_rows !=3D vc->vc_rows || + vc->vc_saved_cols !=3D vc->vc_cols; + if (uni_lines_stale) + vc_uniscr_free(vc->vc_saved_uni_lines); + else + vc_uniscr_set(vc, vc->vc_saved_uni_lines); vc->vc_saved_uni_lines =3D NULL; restore_cur(vc); /* Update the entire screen */