CVE-2023-54264

What it actually does

Null pointer dereference in the sysv filesystem when sb_getblk returns NULL and the code proceeds to lock the block without checking.

Why it matters to the business

Kernel panic or system crash possible on Linux systems mounting or accessing sysv-formatted filesystems under specific conditions, leading to denial of service and potential data unavailability.

How an attack unfolds

An attacker with local access crafts or supplies a sysv filesystem image that causes sb_getblk to return NULL for a parent block, then triggers the code path that dereferences the pointer without a prior NULL check, resulting in a crash.

How to fix it

Apply the fix from commit e976988bc245ec3768cc0f76bed7d05488a7dd0f or upgrade to a kernel version containing this patch; rebuild and deploy the updated kernel across affected systems.

How to confirm the fix worked

Verify the presence of the null check after sb_getblk in the sysv source, confirm kernel version includes the commit, and test mounting of sysv images that previously triggered the NULL path.

Typical attack path

1. Obtain or create a malicious sysv filesystem image
2. Mount the image or perform filesystem operations that invoke the affected sysv code path
3. Trigger sb_getblk to return NULL
4. Execute operations that take a lock on the NULL pointer

How to detect it

Inspect kernel logs for NULL pointer dereference oops in sysv code paths; look for filesystem mount or access attempts preceding crashes.

What your security team should do

• Prioritize patching Linux kernels to include the referenced commit
• Review systems using legacy sysv filesystems for exposure
• Monitor for kernel oops or panic events related to sysv