CVE-2024-53167

What it actually does

NULL pointer dereference in bl_unregister_scsi during nfs4_deviceid_purge_client when a pNFS SCSI layout nfs4_deviceid_node is created but the block device lookup fails to attach a valid block_device to pnfs_block_dev.

Why it matters to the business

Unmounting affected NFS shares with pNFS block layouts can trigger kernel crashes, causing system instability, service outages, and potential data corruption on Linux systems using the NFS client.

How an attack unfolds

An attacker with local access mounts a pNFS SCSI layout-enabled NFS share where block device attachment fails, then triggers client cleanup paths such as unmount or server destruction, dereferencing a NULL block_device pointer in the blocklayout driver.

How to fix it

Update the Linux kernel to a version containing the fix that guards bl_unregister_scsi with the PNFS_BDEV_REGISTERED flag; apply the referenced commit that prevents the premature unregistration path.

How to confirm the fix worked

Confirm the PNFS_BDEV_REGISTERED flag check exists before the dereference in blocklayoutdriver code and reproduce unmount scenarios without triggering the NULL dereference.

Typical attack path

1. Mount NFS share configured for pNFS SCSI layout
2. Force deviceid node creation without successful block device registration
3. Trigger nfs4_deviceid_purge_client or nfs_free_server during unmount or client teardown
4. Execute bl_unregister_scsi on the invalid node causing NULL dereference

How to detect it

Inspect kernel logs for NULL pointer dereference stack traces involving bl_unregister_scsi, bl_free_device, nfs4_put_deviceid_node, or nfs4_deviceid_purge_client during unmount or NFS client destruction.

What your security team should do

• Prioritize kernel updates on systems using pNFS block layouts
• Audit NFS client configurations for SCSI layout usage
• Enable kernel panic logging and monitoring for blocklayout oops
• Test unmount and client teardown paths after patching