CVE-2025-68797

What it actually does

A NULL pointer dereference occurs in the applicom driver's ac_ioctl function when command 6 is processed without validating IndexCard or the RamIO pointer, causing an unconditional readb on a potentially NULL address.

Why it matters to the business

Systems using affected Linux kernels with the applicom driver loaded risk kernel panics and unplanned reboots when the vulnerable ioctl path is exercised, leading to loss of availability for dependent workloads.

How an attack unfolds

An attacker with local access to the applicom device node issues an ioctl with cmd equal to 6; because validation is bypassed for this global query command, a non-existent board index results in dereferencing a NULL RamIO pointer and a kernel crash.

How to fix it

Upgrade the Linux kernel to a revision containing commit 5a6240804fb7bbd4f5f6e706955248a6f4c1abbc, which adds the required early return for cmd 6 before the readb access.

How to confirm the fix worked

Confirm the presence of the conditional skip for cmd 6 in ac_ioctl within the running kernel source or binary; test by exercising ioctl command 6 on systems without configured boards and verify no NULL dereference occurs.

Typical attack path

1. Locate a host exposing the applicom character device
2. Obtain local user privileges sufficient to open and ioctl the device
3. Invoke ioctl with command value 6 against a board index that has no initialized RamIO mapping
4. Trigger kernel NULL dereference and subsequent panic

How to detect it

Inspect kernel logs (dmesg, journalctl) for oops or panic entries referencing ac_ioctl, applicom, or a NULL pointer dereference originating from the char driver path.

What your security team should do

• Apply the referenced kernel commit or a later stable release containing the fix
• Blacklist or unload the applicom module on systems where the hardware is absent
• Restrict unprivileged access to the applicom character device via udev rules or DAC