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/m
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
wifi: mac80211: don't offload TC setup on AP_VLAN interfaces
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.
wifi: mac80211: abort chanswitch when leaving a mesh
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.
wifi: mac80211: reset state when starting AP fails
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_
wifi: mac80211: reset the LED state when ifup fails
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
wifi: mac80211: only operate on TDLS peers in the TDLS code
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.
wifi: mac80211: unlist vifs when their netdev is unregistered
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()!
.
wifi: cfg80211: get the wiphy out of a dying network namespace
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
dy
wifi: mac80211: don't allow injecting frames wider than the chanctx
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.
wifi: mac80211: add HE 6 GHz capability in the scan elems len
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().
wifi: mac80211: mesh: reset the CSA state when leaving
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.
wifi: mac80211: mesh: release the channel if start fails
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_m
wifi: mac80211: set up the TX info early to fix failure paths
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.
RDMA/siw: Bound fragmented header copies by the remaining length
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 rec
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
netfilter: nft_nat: fully initialise new_addr in netmap setup
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.
netfilter: nf_nat: unregister and release hooks on error
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.
netfilter: flowtable: hold reference on ct until flow is released
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.
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr
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
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.
In the Linux kernel, the following vulnerability has been resolved:
neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.
NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses
.validation_type, so no validation is applied:
# ynl --family rt-neigh --do setneightbl \
--json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}'
# ynl --family rt-neigh --dump getneightbl --output-json | \
jq '.[] | select(.name == "arp_cache" and has("config"))
| .parms["interval-probe-time-ms"]'
0
Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is
silently cast to u32, so a larger value can bypass the min
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
ALSA: pcm: set timer->private_data before registering the PCM timer
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: set timer->private_data before registering the PCM timer
snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer->private_data = substream.
Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop()