CVE-2022-48747

What it actually does

bio_truncate() uses an incorrect page offset when clearing buffers beyond the last block of a block device, causing uninitialized kernel memory to be returned on read instead of zeroed data under concurrent truncated/corrupted filesystem and userspace bdev access conditions.

Why it matters to the business

Potential exposure of sensitive kernel memory contents to userspace processes on affected Linux systems, increasing risk of information leakage in environments with block device access and filesystem corruption scenarios; widespread kernel deployment heightens operational exposure until patched versions are deployed.

How an attack unfolds

An attacker with local access arranges a truncated or corrupted filesystem on a block device, then issues userspace reads via the block device interface targeting the final block; the flawed offset calculation in bio_truncate returns uninitialized data from kernel memory rather than cleared content.

How to fix it

Upgrade Linux kernel to a fixed version such as 5.4.176 or apply commit 6cbf4c731d7812518cd857c2cfc3da9fd120f6ae (and equivalent stable backports); rebuild and reboot into the patched kernel; verify the fix is present via kernel version checks.

How to confirm the fix worked

Confirm running kernel version matches or exceeds a listed fixed release; inspect source for the corrected offset calculation in bio_truncate; test with crafted truncated filesystem and bdev read workloads to ensure only zeroed data is returned.

Typical attack path

1. Identify or induce a truncated/corrupted filesystem on a block device
2. Use userspace tools or code to open and read the block device past the last valid block
3. Trigger bio_truncate path during read operation
4. Capture uninitialized kernel memory returned in the response buffer

How to detect it

Review kernel logs and audit trails for unexpected non-zero data patterns in block device reads following filesystem truncation events; examine process activity involving bdev opens and reads on potentially corrupted volumes; no specific post-exploitation artifacts are typically logged.

What your security team should do

• Prioritize kernel upgrades on all systems exposing block devices to untrusted userspace processes
• Monitor for filesystem corruption events that could trigger the condition
• Apply the specific fixed versions listed for each stable tree branch
• Reboot after upgrade and validate with kernel self-tests or custom read probes