Re: [PATCH] char: applicom: fix NULL pointer dereference in ac_ioctl

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Nov 28, 2025, at 08:53, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
>
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
>
> In ac_ioctl, the validation of IndexCard and the check for a valid
> RamIO pointer are skipped when cmd is 6. However, the function
> unconditionally executes readb(apbs[IndexCard].RamIO + VERS) at the
> end.
>
> If cmd is 6, IndexCard may reference a board that does not exist
> (where RamIO is NULL), leading to a NULL pointer dereference.
>
> Fix this by skipping the readb access when cmd is 6, as this
> command is a global information query and does not target a specific
> board context.
>
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

> @@ -835,7 +835,10 @@ static long ac_ioctl(struct file *file, unsigned 
> int cmd, unsigned long arg)
>  		ret = -ENOTTY;
>  		break;
>  	}
> -	Dummy = readb(apbs[IndexCard].RamIO + VERS);
> +
> +	if (cmd != 6)
> +		Dummy = readb(apbs[IndexCard].RamIO + VERS);
> +
>  	kfree(adgl);

This is clearly a correct change, and your description explains
the issue well.

I see the driver was originally merged 26 years ago in 2.3.17
but hasn't changed much. The bug was in the original version,
and probably in the earlier SCO Unix driver before it. The
driver is clearly unmaintained and goes against all principles
of modern kernel drivers.

Unlike the mwave driver I suggested removing earlier, I think
this one may theoretically still have users, at least I see
nothing that stops it from working, and one can still buy
the hardware. On the other hand, there was never really an
attempt to add support for newer hardware models including
PCIe parts, so presumably any users would have other drivers.

     Arnd