wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler
The firmware-controlled num_msg field (u8, 0-255) drives the loop in
ath6kl_wmi_tx_complete_event_rx() without validation against the buffer
length. This allows out-of-bounds reads of up to 1020 bytes past the
WMI event buffer when the firmware sends an inflated num_msg.
Add a check that the buffer is large enough to hold the fixed struct
and the num_msg variable-length entries.
wifi: ath6kl: fix OOB read from firmware IE lengths in connect event
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath6kl: fix OOB read from firmware IE lengths in connect event
The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len
fields in ath6kl_wmi_connect_event_rx() are not validated against the
buffer length. Their sum (up to 765) can exceed the actual WMI event
data, causing out-of-bounds reads during IE parsing and state corruption
of wmi->is_wmm_enabled.
Add a check that the total IE length fits within the buffer.
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read
When the firmware sends a command response with a length mismatch,
carl9170_cmd_callback() logs the mismatch and calls carl9170_restart()
but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4).
Since len comes from the firmware and can exceed ar->readlen, this
copies more data than the readbuf was allocated for.
Bound the memcpy to min(len - 4, ar->readlen) so that the response
is still completed -- avoiding repeated restarts from queued garbage --
while preventing an overread past the resp
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
wifi: carl9170: fix OOB read from off-by-two in TX status handler
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: fix OOB read from off-by-two in TX status handler
The bounds check in carl9170_tx_process_status() uses
`i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing
2 extra iterations past valid _tx_status entries when the firmware-
controlled hdr.ext exceeds hdr.len/2. Fix by using the correct
comparison `i >= (cmd->hdr.len / 2)`.
Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht
wifi: carl9170: fix buffer overflow in rx_stream failover path
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: fix buffer overflow in rx_stream failover path
The failover continuation in carl9170_rx_stream() copies the full tlen
from the second USB transfer instead of capping at rx_failover_missing
bytes. When both transfers are near maximum size, the total exceeds the
65535-byte failover SKB, triggering skb_over_panic.
Limit the copy size to the missing byte count.
[Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]
In the Linux kernel, the following vulnerability has been resolved:
smb: client: validate DFS referral PathConsumed
parse_dfs_referrals() validates that the response contains the fixed
referral entry array and, on for-next, the per-referral string offsets.
However, the response also contains a PathConsumed value that is later
used for DFS path parsing.
If a malformed response provides a PathConsumed value larger than the
search name, later DFS parsing can advance beyond the end of the path.
Validate PathConsumed against the search name length before storing it in
the parsed referral.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: occ: validate poll response sensor blocks
The OCC poll response parser walks a counted list of sensor data blocks.
It used the static backing-array capacity as the parse boundary, but a
transport response makes only data_length bytes current and valid. A
truncated response can therefore make the parser consume a block header or
block extent outside the current response.
Use data_length as the parent boundary, prove the fixed poll header and
each current block header before reading them, and prove the complete block
before advancing. Keep parsed sensor metadata local
net/packet: avoid fanout hook re-registration after unregister
In the Linux kernel, the following vulnerability has been resolved:
net/packet: avoid fanout hook re-registration after unregister
packet_set_ring() temporarily detaches a socket from packet delivery while
reconfiguring its ring. It records the previous running state, clears
po->num, unregisters the protocol hook when needed, drops po->bind_lock,
and later restores po->num and re-registers the hook from the saved
was_running value.
That unlocked window can race with NETDEV_UNREGISTER. The notifier can
observe the socket as not running, skip __unregister_prot_hook(), and
invalidate the per-socket binding by setting po->ifindex to -1 and cle
rds: drop incoming messages that cross network namespace boundaries
In the Linux kernel, the following vulnerability has been resolved:
rds: drop incoming messages that cross network namespace boundaries
rds_find_bound() looks up the destination socket using a global
rhashtable keyed solely on (addr, port, scope_id). Network namespaces
are not part of the key, so a sender in netns A can deliver an incoming
message (inc) to a socket that lives in a different netns B.
When this happens, inc->i_conn points to an rds_connection whose c_net
is netns A, but the receiving rs lives in netns B. Once the child
process that created netns A exits, cleanup_net() calls
rds_loop_exit_net() -> rds_loop_kill_conns() -> r
iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()
need_sync is a per-IOMMU flag shared by all domains and devices behind
that IOMMU. It is set whenever a command is queued with sync == true and
cleared when a completion-wait (CWAIT) command is queued. However, a
cleared need_sync only means that a covering CWAIT has been queued, not
that all previously queued commands have actually completed in hardware.
iommu_completion_wait() read need_sync locklessly and returned early
when it was false. This breaks the "block until all previously queu
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
nfp: Check resource mutex allocation
In the Linux kernel, the following vulnerability has been resolved:
nfp: Check resource mutex allocation
nfp_cpp_resource_find() allocates a CPP mutex handle for the matching
resource-table entry and then reports success. nfp_resource_try_acquire()
immediately passes that handle to nfp_cpp_mutex_trylock().
However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens
for a matching table entry, the resource lookup still returns success and
the following trylock dereferences a NULL mutex pointer while opening the
resource.
nfp_resource_acquire() already treats failure to allocate the table mutex
as -ENOMEM. Do the same for the
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
wan: wanxl: Only reset hardware after BAR mapping
In the Linux kernel, the following vulnerability has been resolved:
wan: wanxl: Only reset hardware after BAR mapping
wanxl_pci_init_one() stores the freshly allocated card in driver data
before the PLX BAR is mapped. Several early probe failures then unwind
through wanxl_pci_remove_one(), including failure to allocate the coherent
status area or to restore the DMA mask.
wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and
wanxl_reset() dereferences card->plx. On those early failures card->plx
is still NULL, so the error path can dereference a NULL MMIO pointer.
Only issue the hardware reset once the BAR mapping exists. The
wifi: mwifiex: bound uAP association event IEs to the event buffer
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: bound uAP association event IEs to the event buffer
mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the
(re)association request IEs that the firmware copies into the event:
sinfo->assoc_req_ies = &event->data[len];
len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control;
sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len;
event->len is supplied by the device firmware and is never validated,
and the subtraction is unchecked. assoc_req_ies points into
adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
iommu/amd: Bound the early ACPI HID map
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Bound the early ACPI HID map
The ivrs_acpihid command-line parser appends entries to a fixed
four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET
parsers, it does not reject a fifth entry before incrementing the map size.
Check the capacity at the common found label before parsing the HID and
UID or writing the entry.
In the Linux kernel, the following vulnerability has been resolved:
tipc: serialize udp bearer replicast list updates
tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with
list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs
from the encap receive softirq (via tipc_udp_rcast_disc()) without
rtnl_lock(), so it can race the cleanup delete and corrupt the list:
list_del corruption. prev->next should be ffff8880298d7ab8,
but was ffff88802449ad38. (prev=ffff888027e3ec98)
kernel BUG at lib/list_debug.c:62!
RIP: __list_del_entry_valid_or_report+0x17a/0x200
Workqueue: events cleanup_bearer
Ca
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled
In the Linux kernel, the following vulnerability has been resolved:
rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst
is never initialized because inet6_init() exits before addrconf_init()
is called to initialize it. An attempt to bind an RDS socket to
an ipv6 address results in a crash in __ipv6_chk_addr_and_flags()
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0
Call Trace:
<TASK>
ipv6_chk_addr+0x3b/0x50
rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp]
rds_trans_get_preferred+0x15d/0x2d0 [rds]
sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the
capacity limit for ep->auth_chunk_list, allowing it to hold up to
20 chunk entries (param_hdr.length up to 24). However, the copy
destination asoc->c.auth_chunks in struct sctp_cookie is only
SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16
chunks are added, sctp_association_init() memcpy overflows the
destination by up to 4 bytes.
Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching
the destination capacity.
sctp: validate stream count in sctp_process_strreset_inreq()
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate stream count in sctp_process_strreset_inreq()
When processing a RESET_IN_REQUEST from a peer,
sctp_process_strreset_inreq() derives the stream count from the
parameter length but does not check whether the resulting
RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.
The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes
larger than the IN request header (sctp_strreset_inreq, 8 bytes).
Generally, the IP payload is bounded to 65535 bytes, so the stream
list cannot be large enough to trigger the overflow. However, on
interfaces with MTU > 65535 (e.g
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
tipc: fix infinite loop in __tipc_nl_compat_dumpit
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix infinite loop in __tipc_nl_compat_dumpit
cmd->dumpit callback can return a negative errno, causing an infinite
loop due to the while(len) condition. As the loop never terminates,
genl_mutex is never released, and other tasks waiting on it starve in D
state.
Check dumpit's return value, propagate it and jump to err_out on error.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix 802.1X-SHA256 call trace warning
Based on wpa_auth as 1x_256 mode, need to set up
"use_fwsup" with BRCMF_PROFILE_FWSUP_1X.
Or it will happen trace warning when call brcmf_cfg80211_set_pmk().
[ 4481.831101] ------------[ cut here ]------------
[ 4481.831102] WARNING: CPU: 1 PID: 2997 at
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac]
[...]
[ 4481.831202] Call Trace:
[ 4481.831204] <TASK>
[ 4481.831205] nl80211_set_pmk+0x183/0x250 [cfg80211]
[ 4481.831233] genl_family_rcv_msg_doit+0xea/0x150