| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: ibss: ref BSS entry for joined event
When the IBSS is joined, we only record the BSSID/channel in the event
and look up the BSS entry when processing it. However, that's racy,
e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a
warning in the event work:
!bss
WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440
Workqueue: cfg80211 cfg80211_event_work
cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144
cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179
cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393
Do the lookup early (the driver is expected to only join an IBSS that
has a BSS entry) and keep a reference to it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't start a ROC while scanning
The ROC work can be pending when a scan starts (which requires
ROC list to be empty, but that's possible), and then a new ROC
can be added to the list and the work will pick it up.
Avoid starting that ROC if a scan made it between things, as
otherwise we'll hit a warning later:
WARNING: net/mac80211/offchannel.c:404 at ieee80211_start_next_roc+0x256/0x2d0
Workqueue: events_unbound cfg80211_wiphy_work
Call Trace:
__ieee80211_scan_completed+0x4fd/0xe40 net/mac80211/scan.c:537
ieee80211_scan_work+0x472/0x1ff0 net/mac80211/scan.c:1193
cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't offload TC setup on AP_VLAN interfaces
AP_VLAN interfaces are purely virtual, so don't try to offload
TC setup to drivers. We can't really use the AP interface either
since we may not know it all the time, and it could technically
even change.
Just reject the TC offload so things get done in software. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: abort chanswitch when leaving a mesh
The code in ieee80211_stop_mesh() leaves CSA active, but leaving
the mesh released the channel context, so the CSA finalize work
crashes:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272
Call Trace:
ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093
ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147
ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542
ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline]
__ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline]
ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155
cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438
Abort the channel switch properly. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reset state when starting AP fails
ieee80211_start_ap() can set enable_beacon (and beacon_int) and fail
later, leaving it set forever. Scanning can then attempt to restore
beaconing on such an interface, leading to:
Oops: divide error: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:mac80211_hwsim_link_info_changed+0xca7/0xf00
Call Trace:
drv_link_info_changed+0x413/0x860 net/mac80211/driver-ops.c:495
ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427
ieee80211_offchannel_return+0x381/0x580 net/mac80211/offchannel.c:160
__ieee80211_scan_completed+0x993/0xe30 net/mac80211/scan.c:519
ieee80211_scan_work+0x472/0x2010 net/mac80211/scan.c:1193
cfg80211_wiphy_work+0x2b7/0x550 net/wireless/core.c:538
in hwsim. Also, cfg80211 then allows changing the interface type,
and the off-channel path getgs confused about beaconing as well,
leading to another warning:
WARNING: net/mac80211/driver-ops.c:468 at drv_link_info_changed+0x583/0x880
ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427
ieee80211_offchannel_stop_vifs+0x328/0x5c0 net/mac80211/offchannel.c:122
ieee80211_start_sw_scan net/mac80211/scan.c:583 [inline]
__ieee80211_start_scan+0xfb6/0x1af0 net/mac80211/scan.c:882
Reset the state on failures to always have it correct. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reset the LED state when ifup fails
When the first interface comes up, the radio LED is turned on. This can
start the TPT trigger timer, which continues running.
But if bringing up the interface fails then the timer keeps running and
won't be stopped by anything, eventually it can be freed:
ODEBUG: free active (active state 0) object: ffff888127e12130 object type: timer_list hint: tpt_trig_timer+0x0/0x300 net/mac80211/led.c:145
WARNING: CPU: 0 PID: 5923 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0
debug_check_no_obj_freed+0x4b7/0x600 lib/debugobjects.c:1129
kfree+0x436/0x670 mm/slub.c:6818
ieee80211_led_exit+0x162/0x1c0 net/mac80211/led.c:210
ieee80211_unregister_hw+0x27e/0x3a0 net/mac80211/main.c:1706
rt2x00lib_remove_dev+0x55b/0x670
Undo the LED state in the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: only operate on TDLS peers in the TDLS code
ieee80211_tdls_oper() can operate on the AP station, which then
yields various warnings when the AP station is removed then or
at a later point in time after being confused for a TDLS peer.
Always check that the station is a TDLS peer. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: unlist vifs when their netdev is unregistered
mac80211 only removes vifs from the local->interfaces list when
an interface is removed via ieee80211_if_remove(), before it
unregisters the netdev. However, it's possible for a netdev to
be unregistered without going through that: When the netns that
holds the wiphy is destroyed, the wiphy is supposed to move to
the init_ns, but that can run into allocation failures.
Then, mac80211 has an interface listed that doesn't exist, and
will eventually hit
BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()!
...
_cfg80211_unregister_wdev+0x24/0x36a [cfg80211]
cfg80211_unregister_wdev+0x15/0x1d [cfg80211]
ieee80211_remove_interfaces+0x1ff/0x257 [mac80211]
ieee80211_unregister_hw+0x73/0x1d1 [mac80211]
mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim]
Remove the interface from the list in ->ndo_uninit if it's still
around to avoid this. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: get the wiphy out of a dying network namespace
When a network namespace is destroyed, cfg80211_pernet_exit() moves any
wiphy back to the initial namespace, and just warns if that fails. But
moving an interface can fail (due to allocation failures), and then the
wiphy is left behind with a garbage netns pointer:
Kernel mode fault at addr 0x30
genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211]
nl80211_notify_wiphy+0xcd/0xe8 [cfg80211]
wiphy_unregister+0x169/0x3fc [cfg80211]
Note that commit debac3a20dec ("net: Remove conflicting altnames for
dying netns in __dev_change_net_namespace().") fixed another path
that could reach it without allocation failures.
Remove interfaces that cannot be moved instead of failing the switch,
so that the wiphy always ends up in the initial namespace. In this
case the netdev core will unregister the interfaces anyway. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't allow injecting frames wider than the chanctx
Frames injected on a monitor interface can carry a radiotap
field requesting a bandwidth, which mac80211 passes down to
the driver regardless of the the actual operational bandwidth.
If the bandwidth requested is too wide, that triggers a warning
in hwsim:
WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw))
Drop such frames entirely instead since they cannot be sent. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: add HE 6 GHz capability in the scan elems len
The HE 6 GHz Band Capability element is in the probe request for
every band if 6 GHz is supported, so add the size to scan_ies_len.
Otherwise, building probe request elements can fail, triggering the
WARN_ON in __ieee80211_start_scan(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: reset the CSA state when leaving
ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed
in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes.
Leaving the mesh while a switch is still pending therefore leaks it.
Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak
in this case, so things can get mixed up in addition to the memory
leak.
Refactor the reset and call it in ieee80211_stop_mesh() to fix it all. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: release the channel if start fails
ieee80211_join_mesh() acquires a channel context and then calls
ieee80211_start_mesh(), which can fail. In that case, the chanctx
isn't released then interface removal will attempt to unassign it
after it's removed from the driver, hitting:
wlan0: Failed check-sdata-in-driver check, flags: 0x0
WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx
ieee80211_assign_link_chanctx
__ieee80211_link_release_channel
ieee80211_link_release_channel
ieee80211_teardown_sdata
unregister_netdevice_many_notify
_cfg80211_unregister_wdev
ieee80211_remove_interfaces
ieee80211_unregister_hw
mac80211_hwsim_del_radio
hwsim_exit_net
Correctly release the channel on start failures. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: set up the TX info early to fix failure paths
The previous commit 2c51457d930f ("wifi: mac80211: free ack status
frame on TX header build failure") cleaned up the leak, but still
left the code a bit messy and the failed SKB didn't get reported
to userspace.
Fix this up by initialising skb->cb[] earlier, which allows using
ieee80211_free_txskb() and therefore reports it for the failure
in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize()
failure path with it. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: pxa: fix double counting of the hw descriptors
pxad_alloc_desc() was converted from
kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT)
to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc
itself - but only where the compiler has __builtin_counted_by_ref(), so
from gcc 15.1 or clang 22.1 on. The loop below it still increments
nb_desc, which makes it come out doubled there and correct elsewhere.
nb_desc is what pxad_free_desc() iterates over and what
set_updater_desc() indexes from, so set it explicitly and drop the
increment. The error path has to lower it to the number of descriptors
allocated so far, otherwise pxad_free_desc() would free entries that were
never allocated. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Bound fragmented header copies by the remaining length
siw_get_hdr() can receive an extended DDP/RDMAP header across more than
one TCP callback. The first callback may receive most of the header,
while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead
of the number of missing bytes. This makes the destination move past the
end of the header and overwrite the receive state, including
fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd
value as a copy offset, which creates an OOB write.
Use the number of header bytes already received when calculating the
next copy length. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_nat: fully initialise new_addr in netmap setup
nft_nat_setup_netmap() builds the mapped address in an on-stack
union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip
member and the loop runs a single 32-bit iteration, but it then copies
the whole 16-byte union into range->min_addr and range->max_addr, so the
upper 12 bytes reach nf_nat_setup_info() uninitialised.
KMSAN reports an uninit-value in nf_nat_setup_info() reached from
nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected.
Zero-initialise new_addr. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_nat: unregister and release hooks on error
If nf_hook_entries_insert_raw() fails, the NAT hooks get never released,
resulting in a memleak.
Postpone setting nat_proto_net->nat_hook_ops when the hooks are
registered to simplify the error path to decide whether the nat hooks
need unwinding. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: hold reference on ct until flow is released
nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe
semantics also allow to refer to the wrong conntrack from the flowtable
datapath. Hold reference on ct until flow is released after rcu grace
period.
Add rcu_barrier() on module exit path, to ensure pending flow entries
are release before module goes away. |
| In the Linux kernel, the following vulnerability has been resolved:
drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr
When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not
set, a drm_pending_vblank_event will be allocated. If later, there is an
allocation failure or another failure at setup_out_fence(), that event
will not have base.fence set and it will not be released at
complete_signaling().
Release the event and set crtc_state->event to NULL just like in the
DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at
drm_event_reserve_init(). That is, prepare_signaling() releases the
event and there is nothing to be done at complete_signaling(). Use
drm_event_cancel_free() as that will also undo drm_event_reserve_init()
in case it has been called. |
