Security and stability in kernel drivers are absolutely critical, especially when those drivers directly interact with hardware. Recently, a subtle but important bug was fixed in the Linux kernel that affected the "appletouch" input driver (which supports Apple laptop touchpads). This post dives deep into CVE-2021-46932, unpacking what went wrong, how it was fixed, and what you need to know.

What Happened?

A race condition was discovered in the Linux kernel’s “appletouch” driver, specifically in how it initialized and handled “work” structures (kernel tasks executed in the background). This bug could lead to system warnings and possible kernel instability because a required function pointer was left uninitialized under certain conditions.

Reported by: syzbot

Technical Details

The root of CVE-2021-46932 is a mis-ordered initialization sequence in the appletouch driver. Here’s the issue, simplified:

- Each device has a work structure (dev->work), basically a task that can be scheduled to run in the background.

input_register_device() registers the device with the kernel's input subsystem.

- In case things go wrong (for example, if the device is closed or removed during registration), cleanup routines may run — particularly cancel_work_sync(&dev->work), which tries to stop any pending tasks.
- However, dev->work wasn’t initialized until _after_ input_register_device() completed. If cleanup happened during registration, cancel_work_sync() could be called while dev->work.func was still unset (NULL).
- This causes a kernel warning in __flush_work(), and could potentially lead to more serious problems.

/ <br>In short:**
Cleanup functions might use an uninitialized structure, leading to undefined behavior.

The Risk

While no direct exploit using this bug has been demonstrated, uninitialized function pointers in the kernel are classic sources of privilege escalation or denial-of-service bugs — code that expects a function to be set might instead call a NULL or random pointer, potentially allowing for attacks under the right (admittedly rare) conditions.

Affected versions:
Linux kernel with the appletouch driver prior to this patch, typically 5.x versions.

The Patch

The fix is simple: initialize dev-&gt;work before registering the device.

Original Vulnerable Code *(simplified snippet)*

// BAD: Work initialized *after* registration
input_register_device(input_dev);
INIT_WORK(&dev->work, appletouch_work);

Fixed Code

// GOOD: Work initialized *before* registration
INIT_WORK(&dev->work, appletouch_work);
input_register_device(input_dev);

This change makes sure that whatever happens during registration or if the device is closed, the cleanup code won’t trip on uninitialized pointers.

Patch commit: git.kernel.org - appletouch: initialize work before device registration

Device attempts to register using the appletouch driver.

2. For some reason, during registration, the input subsystem or user triggers cleanup (closing the device).
3. Cleanup (cancel_work_sync()) gets called, but since dev->work isn’t initialized yet, it tries to execute a NULL or random function.
4. Kernel prints a warning. If exploitation is possible, an attacker could prepare memory before registration and try to hijack control flow.

Note: In practice, exploitation is difficult, but on systems allowing unprivileged access to input devices, theoretically a local user might be able to crash the system or escalate privileges in edge cases.

Mitigation and Recommendations

- Upgrade your kernel! If you rely on the appletouch driver (macbook touchpads on Linux), ensure you use a kernel with the patch included (Linux 5.12+).
- Minimize untrusted users’ access to custom input devices. Most home users aren’t at risk, but enterprise environments should monitor updates.

References

- CVE-2021-46932 at NVD
- Patch commit: appletouch - initialize work before device registration
- Syzbot bug tracker
- Linux Kernel Input Documentation

In Summary

CVE-2021-46932 is a great example of how even small details, like when you initialize a structure, can have big security and stability impacts in kernel code. The fix is simple, the danger is relatively limited, but it’s a reminder that careful sequencing matters — especially at the heart of an OS!

If you maintain Linux systems with desktop Apple hardware, patch as soon as practical. And as always, keep up with kernel security advisories.

Timeline

Published on: 02/27/2024 10:15:07 UTC
Last modified on: 04/10/2024 18:02:06 UTC