From: Helge Deller <deller@gmx.de>
To: Jari Ruusu <jariruusu@protonmail.com>, Jiri Slaby <jirislaby@kernel.org>
Cc: Yi Yang <yiyang13@huawei.com>, GONG Ruiqi <gongruiqi1@huawei.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Text mode VGA-console scrolling is broken in upstream & stable trees
Date: Sat, 2 Aug 2025 21:54:56 +0200 [thread overview]
Message-ID: <77748e07-8411-4ec1-98d3-496fe6ebda38@gmx.de> (raw)
In-Reply-To: <7_oOa5sZXTsEK5rGL7HpT4HfjvhfpGa8r69NDAZWuKTxWP1ONLD9yDbrfJ3nzfducuK8TpC-fF1llnfVjpGHzdmhdzDq7FvvoOYU9eEX9Uc=@protonmail.com>
On 7/31/25 18:12, Jari Ruusu wrote:
> On Thursday, July 31st, 2025 at 10:22, Jiri Slaby <jirislaby@kernel.org> wrote:
>> At the time this was posted (privately and on security@), I commented:
>> =====
>> > --- a/drivers/video/console/vgacon.c
>> > +++ b/drivers/video/console/vgacon.c
>> > @@ -1168,7 +1168,7 @@ static bool vgacon_scroll(struct vc_data *c, unsigned int t, unsigned int b,
>> > c->vc_screenbuf_size - delta);
>> > c->vc_origin = vga_vram_end - c->vc_screenbuf_size;
>> > vga_rolled_over = 0;
>> > - } else
>> > + } else if (oldo - delta >= (unsigned long)c->vc_screenbuf)
>> > c->vc_origin -= delta;
>>
>> IMO you should also add:
>> else
>> c->vc_origin = c->vc_screenbuf;
>>
>> Or clamp 'delta' beforehand and don't add the 'if'.
>> =====
>> That did not happen, AFAICS. Care to test the above suggestion?
>
> My reading of the code in vgacon_scroll() is that it directly
> bit-bangs video-RAM and checks that scroll read/write accesses
> stay in range vga_vram_base...vga_vram_end-1.
>
> Checking that c->vc_origin end up being >= c->vc_screenbuf is
> wrong because in text mode it should be index to video-RAM.
Yes, correct.
> Quote from original "messed up" patch, fix for CVE-2025-38213:
>> By analyzing the vmcore, we found that vc->vc_origin was somehow placed
>> one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and
>> further writings to /dev/vcs caused out-of-bounds reads (and writes
>> right after) in vcs_write_buf_noattr().
>>
>> Our further experiments show that in most cases, vc->vc_origin equals to
>> vga_vram_base when the console is in KD_TEXT mode, and it's around
>> vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a
>> TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around
>> vc->vc_screenbuf while the console is in KD_TEXT mode, and then by
>> writing the special 'ESC M' control sequence to the tty certain times
>> (depends on the value of `vc->state.y - vc->vc_top`), we can eventually
>> move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on
>> QEMU:
>
> To me that sounds like the bug is in TIOCL_SETVESABLANK ioctl().
> It should not be changing c->vc_origin to point elsewhere
> other than video-RAM when the console is in text mode.
Yes, agreed.
> How about adding a check to begining of vgacon_scroll() that
> bails out early if c->vc_origin is not a valid index to video-RAM?
Possible, but that's more of a work-around.
It would be nice to find and fix the real problem.
I tried to reproduce the issue with the provided testcase from
the original patch, but so far I failed.
For now I've added a Revert of the original patch to the fbdev git tree,
so that VGA backward scrolling works again. This gives some time to
fix the KASAN report.
Helge
prev parent reply other threads:[~2025-08-02 19:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 14:06 Text mode VGA-console scrolling is broken in upstream & stable trees Jari Ruusu
2025-07-30 14:26 ` Greg Kroah-Hartman
2025-07-30 15:20 ` Salvatore Bonaccorso
2025-07-31 7:22 ` Jiri Slaby
2025-07-31 16:12 ` Jari Ruusu
2025-08-02 19:54 ` Helge Deller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77748e07-8411-4ec1-98d3-496fe6ebda38@gmx.de \
--to=deller@gmx.de \
--cc=gongruiqi1@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=jariruusu@protonmail.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yiyang13@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox