Re: [BUG] KASAN: vmalloc-out-of-bounds Read in imageblit

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The proposed patch consists entirely of artificial delays and hardcoded process name checks meant for a fuzzer reproducer. It introduces user-controllable `mdelay()` calls, which allows local users to trigger soft lockups and Denials of Service (DoS) under critical locks like the console lock.

Pre-existing issues:
- [High] Pre-existing vulnerability: A race condition exists between console initialization, font/geometry changes, and character rendering, leading to a KASAN vmalloc-out-of-bounds read in `imageblit`.
--

--- Patch [1]: [BUG] KASAN: vmalloc-out-of-bounds Read in imageblit ---
commit dcf37f3f2180abb3c3000d7b65ab0ea65910d9e2
Author: Jaeyoung Chung <jjy600901@snu.ac.kr>

KASAN: vmalloc-out-of-bounds Read in imageblit
    
This commit is a bug report for a vmalloc-out-of-bounds read in imageblit
found by a fuzzer. It includes a reproducer patch that adds artificial delays
and process name checks to reliably trigger the race condition.

> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 23b3c536d53d1..774a38378aa5b 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
[ ... ]
> @@ -1231,6 +1233,13 @@ static void fbcon_init(struct vc_data *vc, bool init)
>  		set_blitting_type(vc, info);
>  	}
>  
> +	if (strncmp(current->comm, "syzrepro0", 9) == 0) {
> +		pr_info("syz_rg: fbcon_init arm vc=%u fg=%d par_rotate=%d fg_con_rotate=%d var=%ux%u\n",
> +			vc->vc_num, fg_console, par->rotate,
> +			fb_display[fg_console].con_rotate,
> +			info->var.xres, info->var.yres);
> +		mdelay(30);
> +	}

[Severity: High]
Is it intentional to include this diagnostic reproducer in the patch?
This introduces a 30ms busy-wait delay based on a user-controllable
process name during console initialization, which allows local users
to trigger soft lockups and Denials of Service under console locks.

>  	par->p = &fb_display[fg_console];

[Severity: High]
This is a pre-existing issue, but does this assignment alter the shared
console state in a way that can race with concurrent geometry computations?

Concurrent execution of fbcon_init(), fbcon_do_set_font(), and cw_putcs()
appears to cause shared state to become unsynchronized, leading to the
vmalloc-out-of-bounds read.

>  }
>  
> @@ -2432,6 +2441,13 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
>  		rows = FBCON_SWAP(par->rotate, info->var.yres, info->var.xres);
>  		cols /= w;
>  		rows /= h;

[Severity: High]
This is a pre-existing issue, but can computing cols and rows using
potentially corrupted or racing par->rotate lead to oversized console
dimensions?

> +		if (strncmp(current->comm, "syzrepro1", 9) == 0) {
> +			pr_info("syz_rg: set_font rot=%d cols=%d rows=%d font=%dx%d var=%ux%u vc=%ux%u\n",
> +				par->rotate, cols, rows, w, h,
> +				info->var.xres, info->var.yres,
> +				vc->vc_cols, vc->vc_rows);
> +			mdelay(10);
> +		}

[Severity: High]
Does this code introduce a 10ms busy-wait delay in the font setting path
that could be exploited for a local Denial of Service?

>  		ret = vc_resize(vc, cols, rows);
>  		if (ret)
>  			goto err_out;
> diff --git a/drivers/video/fbdev/core/fbcon_cw.c b/drivers/video/fbdev/core/fbcon_cw.c
> index bde820967eb9a..f93a4364f89c1 100644
> --- a/drivers/video/fbdev/core/fbcon_cw.c
> +++ b/drivers/video/fbdev/core/fbcon_cw.c
[ ... ]
> @@ -137,6 +139,14 @@ static void cw_putcs(struct vc_data *vc, struct fb_info *info,
>  	image.width = vc->vc_font.height;
>  	image.depth = 1;

[Severity: High]
This is a pre-existing issue, but does reading from vc->vc_font without
sufficient synchronization propagate out-of-bounds parameters to the blitter
when vc_cols * vc->vc_font.width > info->var.yres?

> +	if (strncmp(current->comm, "syzrepro", 8) == 0 &&
> +	    vc->vc_cols * vc->vc_font.width > info->var.yres) {
> +		pr_info("syz_rg: cw_putcs pre-oob yy=%d xx=%d dx=%u dy=%u iw=%u cols=%u font=%ux%u yres=%u yvirt=%u vxres=%u\n",
> +			yy, xx, image.dx, image.dy, image.width,
> +			vc->vc_cols, vc->vc_font.width, vc->vc_font.height,
> +			info->var.yres, info->var.yres_virtual, vxres);
> +		mdelay(5);
> +	}

[Severity: High]
Could this 5ms busy-wait delay in the character output path also be used
to trigger soft lockups by local users?

>  	if (attribute) {
>  		buf = kmalloc(cellsize, GFP_KERNEL);
>  		if (!buf)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819192516.57820-1-jjy600901@snu.ac.kr?part=1