CVE-2021-47468

What it actually does

The mISDN ISDN driver invokes card->isac.release() while holding a spinlock or from atomic context in nj_release, violating kernel rules against sleeping in such contexts and triggering BUG warnings or potential crashes during device removal or module unload.

Why it matters to the business

Systems using legacy ISDN hardware may experience unexpected kernel panics and reboots during hardware events, causing service interruptions in environments still dependent on older telephony drivers; low overall risk given age and minimal exploit activity.

How an attack unfolds

An attacker or administrator triggers PCI device removal or module unload on affected netjet hardware; the nj_release path acquires a lock, calls into isac_release which attempts sleeping operations like work flushing, and the kernel panics due to the invalid context, resulting in denial of service.

How to fix it

Apply upstream kernel patches that restructure the release sequence to invoke card->isac.release() after dropping the lock; rebuild and deploy updated kernels on affected distributions.

How to confirm the fix worked

Reproduce device removal in a test environment and confirm absence of the 'sleeping function called from invalid context' BUG in dmesg; inspect source for the reordered release call after spin_unlock.

Typical attack path

1. Gain local access or trigger hardware events on a system with netjet/mISDN drivers loaded
2. Initiate PCI device removal or modprobe/rmmod sequence
3. nj_release acquires lock and enters atomic context
4. isac_release is invoked before lock release, attempting flush_work or similar sleeping call
5. Kernel hits ___might_sleep BUG and panics

How to detect it

Search kernel logs and dmesg for entries containing 'BUG: sleeping function called from invalid context', 'nj_release', 'mISDN_freedchannel', or 'isac_release' during device removal events; correlate with modprobe or pci_device_remove activity.

• BUG: sleeping function called from invalid context at kernel/workqueue.c
• nj_release+0x69/0x500 [netjet]
• isac_release+0x210/0x260 [mISDNipac]
• mISDN_freedchannel+0xe8/0x100
• in_atomic(): 1, irqs_disabled(): 1

What your security team should do

• Prioritize kernel updates on any remaining ISDN-equipped systems despite low EPSS
• Disable or remove mISDN/netjet modules if hardware is not required
• Monitor kernel logs for the specific atomic context BUG signature
• Review downstream dependent packages for backported fixes given 880 days since publication