wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects

Summary

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

Timeline

1. Jul 12, 2024, 12:25 PM UTCCVE published
2. Sep 10, 2024, 5:04 PM UTCCISA SSVC assessment

   Exploitation: none · Automatable: no · Technical impact: partial

3. Oct 15, 2026, 12:45 AM UTCRecord last updated

Affected versions

• Linux 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 Linux

  2.6.26

• KernelLinux

  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

References 8