CVE-2021-47353

What it actually does

NULL pointer dereference in udf_symlink when udf_tgetblk returns NULL from sb_getblk and epos.bh is dereferenced without validation.

Why it matters to the business

Potential kernel crashes or denial of service on systems mounting or creating symlinks on UDF filesystems under memory pressure.

How an attack unfolds

An attacker triggers symlink creation on a UDF volume while forcing sb_getblk to fail, causing the unchecked NULL buffer head to be dereferenced and the kernel to panic.

How to fix it

Apply the upstream fix that adds an explicit NULL check for epos.bh returned by udf_tgetblk before use; update to a kernel containing commit 7fc27fe692abccaed7e2e0ebfea2aadf5140593f or later equivalent.

How to confirm the fix worked

Confirm the patch is present by inspecting udf/symlink.c for the added NULL validation on epos.bh and test symlink creation under simulated allocation failure.

Typical attack path

1. Mount or access a UDF filesystem
2. Force low-memory conditions to make sb_getblk return NULL
3. Invoke udf_symlink path without epos.bh check
4. Trigger NULL dereference and kernel crash

How to detect it

Review kernel logs for oops or panic traces containing udf_symlink and sb_getblk; look for UDF filesystem activity immediately preceding the crash.

What your security team should do

• Prioritize kernel updates on any system using UDF filesystems
• Monitor for kernel oops involving udf_symlink
• Disable UDF module if not required