Linux kernel -stable discussions
 help / color / mirror / Atom feed
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

      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