linux-kernel - Re: [PATCH] char: applicom: fix NULL pointer dereference in ac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <5c4965c8-dcec-4faf-bd87-19ca7665fedc@app.fastmail.com>
Date: Fri, 28 Nov 2025 13:17:55 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Tianchu Chen" <tianchu.chen@...ux.dev>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] char: applicom: fix NULL pointer dereference in ac_ioctl

On Fri, Nov 28, 2025, at 08:53, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@...cent.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@...cent.com>

Acked-by: Arnd Bergmann <arnd@...db.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