[PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write

[PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write

[yuhaocheng035]

From: Haocheng Yu <yuhaocheng035@gmail.com>

A KASAN: slab-out-of-bounds Write in do_con_write issue is reported by 
a modified Syzkaller-based kernel fuzzing tool that we developed. The 
report indicates the problem lies in vc_con_write_normal 
drivers/tty/vt/vt.c:3141(scr_writew(tc, (u16*)vc->vc_pos)), which writes 
2 bytes to the right of the allocated region at 2634 bytes.

Since it did not provide any repro program or enough information, 
the cause remains unclear. However, adding a validity check of vc->vc_pos 
before scr_writew should avoid this issue.

Signed-off-by: Haocheng Yu <yuhaocheng035@gmail.com>
---
 drivers/tty/vt/vt.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 6e0089b85c27..95d860f09837 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
 			      (tc &  0xff);
 		tc |= (vc_attr << 8) & ~himask;
 
+		unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;
+
+		if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
+				 end < vc->vc_origin ||
+				 vc->vc_pos < vc->vc_origin ||
+				 vc->vc_pos > end - 2))
+			return -1;
+
 		scr_writew(tc, (u16 *)vc->vc_pos);
 
 		if (con_should_update(vc) && draw->x < 0) {

base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
-- 
2.51.0

Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write

[Greg Kroah-Hartman]

On Sat, Mar 21, 2026 at 02:23:12PM +0800, yuhaocheng035@gmail.com wrote:
> From: Haocheng Yu <yuhaocheng035@gmail.com>
> 
> A KASAN: slab-out-of-bounds Write in do_con_write issue is reported by 
> a modified Syzkaller-based kernel fuzzing tool that we developed. The 
> report indicates the problem lies in vc_con_write_normal 
> drivers/tty/vt/vt.c:3141(scr_writew(tc, (u16*)vc->vc_pos)), which writes 
> 2 bytes to the right of the allocated region at 2634 bytes.
> 
> Since it did not provide any repro program or enough information, 
> the cause remains unclear. However, adding a validity check of vc->vc_pos 
> before scr_writew should avoid this issue.
> 
> Signed-off-by: Haocheng Yu <yuhaocheng035@gmail.com>

What commit caused this problem to show up?

And without more information, or a reproducer, I'm a bit loath to take
this change.

> ---
>  drivers/tty/vt/vt.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 6e0089b85c27..95d860f09837 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
>  			      (tc &  0xff);
>  		tc |= (vc_attr << 8) & ~himask;
>  
> +		unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;

Ideally do not create new variables in the middle of a function,
checkpatch should have warned about this.

> +
> +		if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
> +				 end < vc->vc_origin ||
> +				 vc->vc_pos < vc->vc_origin ||
> +				 vc->vc_pos > end - 2))

That's not good, if panic-on-warn is enabled, as it is in a few billion
Linux systems, you just rebooted the machine, turning a simple overwrite
into a denial-of-service, not fixing anything at all, but making it
worse :(

> +			return -1;

Do not make up error numbers :(

thanks,

greg k-h

Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write

[Greg Kroah-Hartman]

On Sat, Mar 21, 2026 at 07:32:34AM +0100, Greg Kroah-Hartman wrote:
> > +			return -1;
> 
> Do not make up error numbers :(

Ah, I see this value being returned elsewhere in this function,
nevermind, my fault.  But really, it should be an -ERROR value, not just
-1.

thanks,

greg k-h

Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write

[Haocheng Yu]

I only ran my fuzzer on v6.18, so I'm unsure what commit caused the issue.

I tried analyzing the cause, but the crash report provided limited information.
I tried directly analyzing the code, but a possible race condition
with vc_do_resize()
is unlikely due to the console_lock, and the state.x out-of-bounds
issue is invalidated
by the restrictions in gotoxy(). Furthermore, no reproducer were
provided, making it
difficult to verify some of my hypotheses.

My initial thought was that although the specific cause was uncertain,
since scr_writew()
causes slab-out-of-bounds writes, adding a check before scr_writew()
would solve the
problem. After reading your explanation, I realize my thinking was
quite naive. Therefore,
I think I may not be able to provide a better patch at the moment.
Please ignore this patch.

BTW, I ran `./scripts/checkpatch.pl --strict` indeed, but it didn't
warn me about the variable
created. I'll pay attention next time.

Anyway, thanks for reviewing my patch.

Best regards,
Haocheng

> What commit caused this problem to show up?
>
> And without more information, or a reproducer, I'm a bit loath to take
> this change.
>
> > ---
> >  drivers/tty/vt/vt.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 6e0089b85c27..95d860f09837 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
> >                             (tc &  0xff);
> >               tc |= (vc_attr << 8) & ~himask;
> >
> > +             unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;
>
> Ideally do not create new variables in the middle of a function,
> checkpatch should have warned about this.
>
> > +
> > +             if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
> > +                              end < vc->vc_origin ||
> > +                              vc->vc_pos < vc->vc_origin ||
> > +                              vc->vc_pos > end - 2))
>
> That's not good, if panic-on-warn is enabled, as it is in a few billion
> Linux systems, you just rebooted the machine, turning a simple overwrite
> into a denial-of-service, not fixing anything at all, but making it
> worse :(
>
> > +                     return -1;
>
> Do not make up error numbers :(
>
> thanks,
>
> greg k-h