CVE-2026-90187: null_blk: free zones array on device power-off

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

nullblk: free zones array on device power-off

nullinitzoneddev() allocates dev->zones when a zoned device is powered on, but nulldeldev() never frees it on power-off; dev->zones is only freed later in nullfreedev(), when the configfs directory is removed. If the device is powered off and then on again, nullinitzoneddev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle.

Free dev->zones in nulldeldev() via nullfreezoneddev() to solve it. And calling nullfreezoneddev() in nullfreedev() is no longer necessary because every caller already invokes nulldeldev() first: via nullbgroupdropitem() before nullbdevicerelease(), in the nulladddev() error path of nullcreatedev(), and in nulldestroydev(). Remove the redundant call.

And take &lock around zonecondstore() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullbdevicerelease() or nullexit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.

Affected Software

1 affected component
Linux Kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Modify the code so that calling null_free_zoned_dev() in null_free_dev() is no longer performed; the redundant free is removed as part of the fix.

    Linux kernel configfs (null_blk zoned device code paths) Remove the redundant call to null_free_zoned_dev() from null_free_dev() = Apply change: eliminate redundant null_free_zoned_dev() call in null_free_dev()
  2. Configuration

    Add taking &lock around zone_cond_store() in both store wrapper functions (the two store wrappers) to ensure thread-safe access.

    Linux kernel null_blk (zone_cond_store) Locking around zone_cond_store() = Use &lock in the two store wrappers
  3. Configuration

    Update null_del_dev() to free dev->zones by calling null_free_zoned_dev(), and ensure dev->zones is freed on power-off so it is not only freed on later configfs directory removal.

    Linux kernel null_blk (null_del_dev/null_free_zoned_dev) Freeing dev->zones on power-off = Free dev->zones in null_del_dev() via null_free_zoned_dev()
  4. Compensating control

    Ensure serialization of dev->zones check-and-deref against its alloc/free across power cycles (device powered off then on again) so that access cannot occur after free; this is implemented by using &lock and/or appropriate locking/guards around check-and-deref.

Event History

Sep 17, 2026
CVE Published
via MITRE·04:07 PM
Data Sourced
via MITRE·04:07 PM
Description

Frequently Asked Questions

1

Which systems are exposed to the memory leak?

Systems using the Linux kernel null_blk driver with a zoned device are affected when that device is powered off and then powered on again. Each such power cycle can allocate a new zones array while losing the pointer to the prior allocation.

2

What happens if the device is removed instead of power-cycled?

The zones array is freed when the device's configfs directory is removed through device cleanup. The leak occurs specifically because power-off did not previously free the array before a later power-on allocated a replacement.

3

What additional synchronization issue does the fix address?

The fix serializes zone_cond_store() checks and dereferences of dev->zones with allocation and freeing of that array. This prevents concurrent store operations from accessing dev->zones while it is being allocated or freed during device state changes.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203