CVE-2022-48870

What it actually does

Null pointer dereference in spk_ttyio_release when in_synth->dev was never initialized during failed speakup module probe, causing kernel crash on module unload via mutex_lock on a null pointer.

Why it matters to the business

Local denial of service that can crash the system during routine module loading and unloading operations; the issue has been public for over two years with no observed exploitation or ransomware use, and low exploit probability.

How an attack unfolds

An attacker with local access loads a speakup synthesizer module such as speakup_audptr in a way that causes tty_kopen_exclusive to fail, leaving in_synth->dev uninitialized, then unloads the module to trigger the null dereference during synth_release.

How to fix it

Update the Linux kernel to commit 2da67bff29ab49caafb0766e8b8383b735ff796f or later; Android wificond users should apply the 2021-03-01 fixes present in versions 9, 10, and 11.

How to confirm the fix worked

Confirm the fix by verifying the presence of the in_synth->dev initialization check in spk_ttyio_release; test module load/unload cycles on affected speakup drivers to ensure no NULL dereference occurs.

Typical attack path

1. Load speakup module variant that triggers initialization failure
2. Trigger module removal via rmmod or delete_module syscall
3. Kernel executes spk_ttyio_release on uninitialized state
4. Null pointer dereference occurs during mutex acquisition

How to detect it

Review kernel logs for oops traces containing mutex_lock called from spk_ttyio_release and synth_remove; search dmesg or syslog for speakup module load failures followed by BUG: kernel NULL pointer dereference.

What your security team should do

• Apply the referenced kernel commit or distribution backport immediately on systems exposing speakup modules
• Restrict unprivileged module loading via kernel module signing and CAP_SYS_MODULE controls
• Monitor for kernel oops reports referencing spk_ttyio_release or speakup during module unload