il3945_pci_probe() calls il_eeprom_init(), which allocates memory for
the EEPROM data. The probe failure paths release this allocation with
il_eeprom_free(), but the remove path does not free it after a
successful probe.
As a result, the EEPROM data is leaked when the PCI device is removed.
Free the EEPROM data in il3945_pci_remove() before releasing the
mac80211 hardware structure.
This issue was found by manual code inspection.
Fixes: 073d3f5f1b ("iwlwifi: changing EEPROM layout handling")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260916073736.2952028-1-lgs201920130244@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
- mac80211: S1G TIM bitmap fix
- ath12k: remove undocumented DT ABI implementation
- various firmware API and over-the-air hardening changes
- fixes for most cfg80211/mac80211 syzbot reports
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmqqVJYACgkQ10qiO8sP
aACbjQ//VK16MorAA6e+zC44Cq68erE/0kCXjkwHjNPFrg8P2gD3qVHtPMUi5GLG
ldWD5Hm3SlmGlpXIljJPQpTaMHGwVG+1j+n4TgwonomXarsaftSriSPKMww3/O2c
kk+LAujowo0OImPNxY4noWRVcEcSo/tsTvbYDcAKjc91yHs/gU6TSeT3E/YFAfbt
HSNbMImaSdTBM6TnvwepGZG2RisKWMgiYhpPFzO26TvoYnXBCgN48kOVz+x/6M0P
o7i3coZiRO1o7ec9SsxgKUZUDNVMNoiEDWPQBJpaq2vOV1eFCrwuJr4/KKYk738F
zSGsIK8z1R6j7RRB2qk3qYRrrwuNS1FZWeo4S0iGWvLwqbL7nsrrvkFc5O9uFure
RV/Uf2okycaIZICe1rSalTDtjWgp6beRQSj3Ep75MSa/iqj6Rtggo9CxM7+aPkoa
z0Q9MKqmuY0yXZCtI0EOayXcOpdoHWot95NJQ5nkR0ge5WJ2tu+myzepesQ9a5Vb
JEOw8N4gJ9Hdst94gDqiGzDQb0xRYeMSgET3we9gA9KMu3NXBrbRLhRbkk+16fdA
DoqbwD6wrH6nXcgihLBEILRLQWHe8pC7PoI2LvuTfzP3xiD50NvRVfdwNDuWLg/+
2uP1Yl4x67vXNUqa619taRwtwFuJn+M31uwZ57eMw3U1edNlfug=
=/zWX
-----END PGP SIGNATURE-----
Merge tag 'wireless-2026-09-16' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Many fixes:
- mac80211: S1G TIM bitmap fix
- ath12k: remove undocumented DT ABI implementation
- various firmware API and over-the-air hardening changes
- fixes for most cfg80211/mac80211 syzbot reports
* tag 'wireless-2026-09-16' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (67 commits)
wifi: brcmsmac: fix UAF in brcms_free_timer()
wifi: brcmfmac: fix lost 802.1x TX completion wakeup
wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all()
wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown
wifi: ath12k: ahb: Revert undocumented ABI and dead code
wifi: mac80211: refuse to make a monitor active when it has no queue
wifi: libipw: reject TKIP frames without a full MIC
wifi: virt_wifi: don't transfer operstate before register
wifi: cfg80211: check if AP has been started or joined a mesh before adding new station
wifi: cfg80211: move link_id validation earlier in nl80211_new_station()
wifi: cfg80211: do not support direct add of station to AP_VLAN interfaces
wifi: cfg80211: verify if AP_VLAN belongs to the correct AP
wifi: mac80211: set up the TX info early to fix failure paths
wifi: mac80211: mesh: release the channel if start fails
wifi: mac80211: mesh: reset the CSA state when leaving
wifi: mac80211: add HE 6 GHz capability in the scan elems len
wifi: mac80211: don't access the TSF of a down interface
wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set
wifi: mac80211: don't allow link changes when iface is down
wifi: mac80211: require a peer station for TDLS setup confirm
...
====================
Link: https://patch.msgid.link/20260916083642.110609-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
libipw_michael_mic_verify() assumes that an skb contains an eight-byte
Michael MIC. A short TKIP frame makes the unsigned payload length wrap,
causing michael_mic() to read past the skb.
Check that the MIC is present before verifying it, and use the existing
MICHAEL_MIC_LEN constant for all MIC lengths in the verifier.
Fixes: b453872c35 ("[NET] ieee80211 subsystem")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Link: https://patch.msgid.link/20260909061124.3802517-1-4ncienth@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Both management receive paths establish a lower bound on the frame
length and no upper bound, even though the length originates from the
device.
ipw2100_corruption_check() returns 0 without inspecting frame_size for
management frames, and __ipw2100_rx_process() only rejects a frame
smaller than the three-address header, so any reported size up to the
u32 limit reaches libipw_rx_mgt() against a receive allocation of
IPW_RX_NIC_BUFFER_LENGTH bytes. Check frame_size itself rather than
stats.len, which is a u16: a size of 65566 truncates to 30 on
assignment and would pass a check made afterwards.
ipw_rx() likewise only rejects a frame shorter than the header length.
Bound it against the DMA mapped receive buffer. The size passed to
alloc_skb() is rounded up by the allocator, so skb_tailroom() can
exceed IPW_RX_BUF_SIZE and is not a usable bound here; the existing
uses of that idiom in the data paths are too permissive for the same
reason.
libipw then hands the remainder to libipw_parse_info_param(), which
walks information elements for as long as the length allows, so an
over-long reported length reads past the receive buffer without any
wraparound being involved.
The length is device-reported, so per
Documentation/process/threat-model.rst this is a robustness fix rather
than a vulnerability.
Found by an AI-assisted review of length arithmetic in management frame
parsers. Compile-tested only for these two hunks; I do not have the
hardware, so they are not tested on a real device.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen <anuk909@gmail.com>
Link: https://patch.msgid.link/20260812190412.18333-4-anuk909@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
libipw_handle_assoc_resp() reads the capability, status and aid fields
of the 30-byte association response prefix and then computes the
information element length as
stats->len - sizeof(*frame)
stats->len is a u16 and sizeof() has type size_t, so the subtraction is
evaluated as size_t and wraps instead of going negative. Truncating
that to the u16 length parameter of libipw_parse_info_param() turns a
frame shorter than the fixed fields into a length near 64 KiB, and the
parser then reads past the receive buffer.
Both the ipw2100 and ipw2200 management receive paths reach this
function having established only that the frame carries the generic
24-byte three-address header.
Reject the frame before any fixed field is touched.
Found by an AI-assisted review of length arithmetic in management frame
parsers. Verified with a KUnit case under Generic KASAN on arm64 under
QEMU; I do not have the hardware, so it is not tested on a real device.
Fixes: 9e8571affd ("[PATCH] ieee80211: Add QoS (WME) support to the ieee80211 subsystem")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen <anuk909@gmail.com>
Link: https://patch.msgid.link/20260812190412.18333-3-anuk909@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
libipw_process_probe_response() and the libipw_network_init() call it
makes assume the frame contains the full 36-byte beacon and probe
response prefix, but the ipw2100 and ipw2200 receive paths only
establish that a management frame carries the generic 24-byte
three-address header.
libipw_network_init() then computes the information element length as
stats->len - sizeof(*beacon)
stats->len is a u16 and sizeof() has type size_t, so the subtraction is
evaluated as size_t and wraps instead of going negative. Truncating
that to the u16 length parameter of libipw_parse_info_param() yields
65524 for a 24-byte beacon, and the parser then walks the receive
buffer as if it held almost 64 KiB of information elements, reading
past the allocation.
Reject the frame before any fixed field is touched.
Found by an AI-assisted review of length arithmetic in management frame
parsers. Verified with a KUnit case under Generic KASAN on arm64 under
QEMU; I do not have the hardware, so it is not tested on a real device.
Fixes: b453872c35 ("[NET] ieee80211 subsystem")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen <anuk909@gmail.com>
Link: https://patch.msgid.link/20260812190412.18333-2-anuk909@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On the error path of __il4965_up(), il_dealloc_bcast_stations() clears
only IL_STA_UCODE_ACTIVE, leaving IL_STA_BCAST set. This causes the
same broadcast stations to be deallocated again by __il4965_down().
This can occur when RF_KILL is toggled during driver startup.
To fix clear the entire 'used' field, since we will not do any
other operations on the station.
Reported-and-tested-by: Martin-Éric Racine <martin-eric.racine+kernel-bugzilla@iki.fi>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221733
Fixes: c2fd34469d ("iwl4965: Fix a memory leak in error handling code of __il4965_up")
Cc: <stable@vger.kernel.org> # 7.1.x: 57aa1718d5 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Cc: <stable@vger.kernel.org> # 6.x.x: 57aa1718d5 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Cc: <stable@vger.kernel.org> # 5.x.x: 57aa1718d5 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260820093059.18779-1-stf_xl@wp.pl
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
- iwlwifi: new FW version support
- mt76:
- mt7928 support
- mt7925 NAN support
- mt7996 AP powersave improvements
- rtw89:
- LED support
- RTL8922DE support
- dual-BT coex for RTL8922D
- ath12k: AHB platform MultiPD support
- cfg80211: pre-assign cookies for operations
- mac80211: AQL support for multicast
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmp0efQACgkQ10qiO8sP
aACLlQ//RIWyRR5ss0/CFHKOasGxbffdlEbByQLpj2lM5z1X1rZEs3+JyHUM3ulf
AqZmlU5vVtiNSgGwcL/2+E1BdUQdWLhnqkjAGHtKDh9LT06eix4e2VMLLqY9WdQ+
E5l1hSfrKck7f1C+orhRhKWbGzWJ5kVuIIARTcPPMMi9VnCzVJ6vuREFgwX8i7j5
xFiLGJSaynL9zQoKSaXhcEpyIMVox/lD1BY3HLuVm9ldJD5+KtLb3vkKgf52DbI6
Cx3znqDfpOzfb3VHnoCWn6GVNTAtZGNA+NM9+RWFIHAe2jIbRfgG7tgDiemC9NJ9
HrmgIMR8uLHc0EPCripsckzENmaAgv6opSb2RAJL7blZ/hSzVulDg+ejVCe87FN6
3joldI2Rwpp90kFLLqm3JV8yrE97mZXPzA7zqt+uvEuHOTRrfskKIk6nDifsnhcn
pK/y9CpqpHyLbvynPS/BPQSyazO+f4GVq7J8mxZXqvV9q9i8g40qjCmp7jKiNCH9
4rWooGTwFRmVcfmnfc0XK/xMC/FrQ7C6grl+YFudP6FxJ1MOyLqApkthO6W4pGIr
spH1s4eaHYdM1l9kOlMfnGtLXF/RBFDX5pSnKRnkZYGklZJxUtrOj1hFc4c0lF0I
lKf2KWf223eFTnSeMe77UozS/C3cDQFBmegdsKzNJaFKsP4mWuc=
=L5q1
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Quite a bunch more work, of note:
- iwlwifi: new FW version support
- mt76:
- mt7928 support
- mt7925 NAN support
- mt7996 AP powersave improvements
- rtw89:
- LED support
- RTL8922DE support
- dual-BT coex for RTL8922D
- ath12k: AHB platform MultiPD support
- cfg80211: pre-assign cookies for operations
- mac80211: AQL support for multicast
* tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (403 commits)
wifi: nxpwifi: bound uAP association event IEs to the event buffer
wifi: nxpwifi: detach sync command buffer on interrupted wait
wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()
wifi: rsi: Fix types to appease CFI
wifi: mac80211: skip default WMM setup for AP_VLAN links
wifi: nxpwifi: fix multiple static analysis errors and warnings
wifi: morsemicro: MM81X should be invisible and selected by its users
wifi: nxp: NXPWIFI should be invisible and selected by its users
wifi: cfg80211: stop PMSR before P2P and NAN teardown
wifi: mac80211: disconnect on CSA to channel 0
wifi: brcmfmac: fix P2P action frame handling without device vif
wifi: brcmfmac: Set DMA direction for msgbuf packet IDs
wifi: brcmfmac: validate msgbuf flowring IDs before use
wifi: mac80211: fix RCU usage in peer probing
wifi: mac80211: fix RCU dereference in throughput estimate
wifi: wilc1000: validate monitor transmit frame headers
wifi: mac80211: skip unused probe response countdown offsets
wifi: zd1211rw: reject secondary interfaces to prevent conflicts
wifi: nl80211: clean up color-change beacon data on errors
wifi: mac80211: send TWT teardown to peer after setup TX failure
...
====================
Link: https://patch.msgid.link/20260806121304.190084-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This comtains the usual features, fixes and cleanups. Notably:
- Small fixes of bugs reported by LLMs
- LARI command version 14 and 15
- MCC command version 10
- Support for core 107
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCamJQLQAKCRDacY7uyt+O
fc/cAQCHQ7F7RCO8iB5u+kFc71+0UpDpK8bYVN1lwvL26/7WkQD/YcRZ9L01EOJl
DZQAP0WwHoHzK6DuPQoxnr88iiUYnAs=
=PyTI
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2026-07-23' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
wifi: iwlwifi: updates - 2026-07-23
This comtains the usual features, fixes and cleanups. Notably:
- Small fixes of bugs reported by LLMs
- LARI command version 14 and 15
- MCC command version 10
- Support for core 107
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
BUG_ON() for il->num_stations < 0 can happen in real word, see
https://bugzilla.kernel.org/show_bug.cgi?id=221733
Replace BUG_ON() with WARN_ON() (and reset the counter to 0) to
do not put whole system to inconsistent state on the condition.
Also allocate debugfs buffer for all stations (32 or 25)
to do not use num_stations since it might not be right.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260724095545.33647-1-stf_xl@wp.pl
[clarify commit message wrt. debugfs buffer]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Firmware API v15 extends LARI config with the DSM function-0 support
bitmap, and host must provide this information for regulatory handling.
Without this, FW cannot use BIOS-reported DSM capability bits.
Add oem_supported_dsm_bitmap to the host LARI config command
definition and wire it into regulatory command construction.
Populate it from DSM query data and keep backward compatibility by
using the pre-v15 command size for command version 14.
Behavior change:
When DSM function-0 data is available, host includes it in the LARI
config command sent to FW; older command versions remain compatible.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20260723142324.c576a8c7560b.I5cc1277d0ef31409f6a3364342a3f35cd9318ceb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
We have a dedicated function to fetch all the BIOS tables when the opmode
starts, and yet we read a couple of tables directly from
iwl_op_mode_mld_start, which is already a large function that does
multiple things.
Move the reading of the sgom, puncturing, and RFI enablement to the
dedicated iwl_mld_get_bios_tables.
Link: https://patch.msgid.link/20260717172958.b19a33e0b507.I73f6b5e6a81d0f411f12589ceb30afa655c0a16b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add a radio debug trace when MCC_ALLOWED_AP_TYPE_CMD is sent
successfully during AP type table initialization.
This improves bring-up visibility without changing runtime behavior.
Failures are still reported through the existing error log path.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20260717172958.18e1fc5ec109.I76dd832f62d00a8f358f8e4a705f25184ac53da2@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
New firmware will support version 2 of the update_mcc notification. The
extra field is used for a new feature, but we does not support it.
Keep the existing payload definition compatible with both versions and
register version 2 in the MLD notification version table so the driver
accepts the newer notification without changing the behavior.
This preserves version 1 support and adds compatibility with firmware
that sends version 2.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20260717172958.9c5a940d37dc.I955800c2377b802ffb99003349552cc4036ca4bd@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
IWL_SAR_ENABLE_MSK and IWL_REDUCE_POWER_FLAGS_POS describe the layout
of the shared WRDS/SAR table format. They are not ACPI-specific: the
same bit positions are used regardless of whether the data originates
from ACPI, UEFI, or another BIOS source.
IWL_SAR_ENABLE_MSK was already duplicated in regulatory.h; remove it
from acpi.h to eliminate the duplication.
Move IWL_REDUCE_POWER_FLAGS_POS to regulatory.h alongside
IWL_SAR_ENABLE_MSK so that both SAR field descriptors live in the
shared regulatory header, accessible to all BIOS configuration sources.
No functional change.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260717172958.32e5dcde4b90.I420c58b05ab6ab011c4c771ca9e4eb62740de549@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When FW crashes on D3 exit, iwl_mld_nic_error() sets
STATUS_RESET_PENDING and queues restart wk, but mac80211's resume
callback synchronously calls iwl_trans_stop_device() which clears
the flag. As a result restart wk skips sw_reset, and the FW error
recovery buffer is never read.
The new FW boots with empty BA state and initial sequence numbers,
while the AP still holds its A-MPDU RX reorder window.
This causes MPDUs to be dropped as IWL_RX_MPDU_REORDER_BA_OLD_SN until
ADDBA is renegotiated.
We don't know how long the firmware has been in an error state
or whether the AP still considers us associated, so keeping the
connection alive is not worth it.
Call ieee80211_resume_disconnect() when iwl_mld_wait_d3_notif() fails,
and let userspace reassociate.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260717172958.3e10c8498f53.Icf5644b42d79e984ecc16abfa873bd37f611e778@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Wake packet parsing only accounted for FCS and missed per-key
IV/ICV overhead for protected data frames.
Prevent size underflow and bad packet trimming when
notifications are malformed or truncated.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260717172958.e06595623533.Ie09494b7e34e5872b750fd90e325648ee469d0da@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reject firmware section TLVs that are shorter than the offset field
before subtracting sizeof(offset) from the section size.
This prevents size underflow for malformed TLVs.
Assisted-by: GitHubCopilot:GPT-5.3-Codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260717173215.17b040b27edc.I6b32d1e9ad707417e2e604f08a63582456209372@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Switch iwl_scan_offload_match_info::matches to a fixed-size array and
adjust D3 netdetect size handling accordingly.
In MVM D3 paths, compute expected payload size as
offsetof(struct iwl_scan_offload_match_info, matches) + matches_len to
preserve previous behavior after the struct layout change.
In MLD D3 netdetect handling, keep the simple full-notification size
assumption and validate against sizeof(*notif) before accessing data.
This keeps scan offload / netdetect functionality unchanged while
making length checks consistent with the new struct definition.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.4c4346140bcc.I44313ac41daca352e6aecdba09a1c3570c3eea06@changeid
When setting the TK for ranging with an associated peer, 32 bytes of
TK are copied from the vif key without verifying the actual key length
which may be only 16 bytes if CCMP-128 is used. Fix it by setting the
copy length according to the key cipher.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.e339570086bd.Iafff5aaf0e25f7d29e06f0ef456107c4062bbc7d@changeid
ba_notif->tid is a firmware-controlled u8 that is used directly
as an array index into tid_data[] without any validation. Add a
bounds check against IWL_MAX_TID_COUNT before dereferencing the
array.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.d7c3e75d47af.If88948108cfc8b5fb3ce5531d927855d1b3b6b30@changeid
mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of
the actual TID value 'tid'. This writes lq_color into a random tid_data
slot unrelated to the BA entry.
Since multi-TID blockack is not really in use, 'i' was always 0 and no
harm was done.
Add a out-of-bound check before accessing the array.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.919edee567eb.Ie85c350e3afe2b39709d0039072740d86660f8ae@changeid
iwl_pcie_init_fw_sec() iterates over LMAC, UMAC, and paging
firmware sections and writes to ctxt_dram->lmac_img[i],
ctxt_dram->umac_img[i], and ctxt_dram->virtual_img[i] without
first verifying that the counts derived from the firmware image
do not exceed the array size. An oversized firmware image could
cause out-of-bounds writes into the fixed-size context-info DRAM
arrays.
Add explicit WARN_ON checks for all three section counts and
return -EINVAL if any is exceeded.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.34db46ca12f3.I1aa225492a62f25293c147aa7293afa80a5d4215@changeid
In iwl_mvm_wowlan_store_wake_pkt(), packet_len was initialized from
notif->wake_packet_length before the explicit check that len >=
sizeof(*notif).
Move the assignment of packet_len to after the size check so that
notif->wake_packet_length is only accessed once the payload length
has been validated.
Fixes: 219ed58fed ("wifi: iwlwifi: mvm: Add support for wowlan wake packet notification")
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.99d5cf85a528.Ic4aa736011d4fe88e0cd19723d1d48bb24642198@changeid
iwl_pnvm_complete_fn() casts pkt->data directly to
struct iwl_pnvm_init_complete_ntfy and reads the status field
without first verifying that the firmware notification payload
is large enough to contain that structure.
Add a WARN_ON_ONCE check against sizeof(*pnvm_ntf) and return
early without reading uninitialised memory if the payload is too
short.
Fixes: b3e4c0f34c ("iwlwifi: move PNVM implementation to common code")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.7f2a669e5c75.I00465dcfcbccb250ae9af2d9bb305e24de1ba394@changeid
The expression list[*size++] increments the pointer 'size'
rather than the u8 value it points to (operator precedence: ++
binds to the pointer before the dereference). As a result the
block-list entry is written at the correct index but *size is
never incremented, so the caller's count stays at zero and
subsequent calls overwrite slot 0 every time.
Change to list[(*size)++] so that the value pointed to by size
is incremented after use as the array index.
Fixes: 5f4656610e ("wifi: iwlwifi: extend TAS_CONFIG cmd support for v5")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.d2cd92242582.Ife4140a4e27be2a1cd9f886c5a9b376ce182a019@changeid
The SMEM parsers cast firmware response payloads directly to shared
memory configuration structures. A short response can leave fields
outside the received payload while the driver still dereferences them.
Check the response payload length before reading the base fields in
both parser variants. Require the full legacy extended layout before
reading internal TX FIFO data. Valid responses keep the same parsed
values.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.fbdb0016a91d.I5f6c6e04589a24a233559191170ccb43372dee63@changeid
The SAR GEO command response is cast to
iwl_geo_tx_power_profiles_resp without verifying the payload length.
A malformed or unexpected firmware response can lead to reading an
invalid structure layout.
Add an explicit size check before accessing the response data and
return -EIO when the payload size is wrong.
Fixes: f604324eef ("iwlwifi: remove iwl_validate_sar_geo_profile() export")
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.7e749b7d374a.I4ef54548bff6c6e7c7a57bee771ac12508aad677@changeid
TX_CMD parsing uses frame_count to walk status entries and then
read the trailing SCD SSN. Make the minimum-length check follow
that exact runtime layout calculation before parsing the payload.
For new TX API, reject TX_CMD responses with frame_count != 1 and
warn/return in the aggregation handler to document that aggregated
accounting is expected via BA notifications.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.0474ee89bab9.I84f151aabecb8921b587da092f29f78c47128f0f@changeid
We need to expect more channels on devices that support UNII-9.
Since iwl_ext_nvm_channels and iwl_uhb_nvm_channels are just a prefix
of iwl_unii9_nvm_channels just use iwl_unii9_nvm_channels and modify the
number of channels if the device does not support UNII-9 channels.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.473f48e6135d.I0e93cda753558aa4d9e3efcdd52cbc2eb9302c4a@changeid
Validate txq_id from TX response notification before passing to
iwl_trans_reclaim(). Other reclaim paths in this file perform this
check to prevent out-of-bounds access on malformed notifications.
Assisted-by: GitHubCopilot:claude-haiku-4.5
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.b938c2dcf08d.I8a88ec359e229f1c41ac9c49fd9ce28a2b62b274@changeid
When a channel context is unassigned, there is a path to cleanup the FW
state in case of NON MLO connection: remove the link and add it again.
However, when the transport is dead, e.g., during device removal etc.,
this flow will fail and as a result the mld_vif->link[0] would be set to
NULL. Later, when the interface is removed, iwl_mld_remove_link() would
warn as the link is NULL.
Fix this by not doing the cleanup when the device is dead.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.89a0c44a72a3.I45cca8b84a25943d5771199af6b0155dbac77b58@changeid
Make sure we don't end-up with a num_frags = 0 situation.
For that, check that the required size is not 0 and put a checker on
num_frags as well.
Fixes: 14124b2578 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.60121deecf2c.Iebc891c95a7bd1b2a093b0bb88532db446a758ee@changeid
When calculating the SAP data length, the code subtracts
sizeof(*ethhdr) from len. If the SAP data header indicates a length
that is shorter than ethernet header length, this will result in an
unsigned underflow which will lead to a kernel panic when trying to
put the data into the SKB. Fix it by skipping a message if the
indicated length is too short.
In addition, if the message type is not SAP_MSG_DATA_PACKET or skb
allocation fails, the loop skips to the next message but without
reading the message payload. This may result in reading the payload
as the next message header, which will lead to errors in parsing the
next messages. Fix it by skipping the message payload as well.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.f66b10736047.I4a1dde517c36561d41358dd82a5cec8b6c886c14@changeid
In iwl_mld_handle_wake_pkt_notif(), expected_size was initialized from
notif->wake_packet_length before the IWL_FW_CHECK that validates the
payload covers sizeof(*notif).
Move the assignment of expected_size to after the size check so that
notif->wake_packet_length is only accessed once the payload length has
been validated.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.94c526d2c66e.I065a19a9dcc7f45a7457667c0f625fcd2c7bf6b6@changeid
There is a new UHB extension bitmap that is part of the LARI
configuration, which needs to be sent to the FW - also frozen ones.
But in frozen FWs we cannot increase the version of an API, since the
driver assumes a specific version, depending on the core number.
In case of a (new) FW that expects the new version and a (old) driver
that doesn't support that new version, the driver will send a default
old version, causing a fw assert about its bad size.
To mitigate this, there is a special command which will be supported
only on those frozen FWs. Old drivers will simply not support/send it,
and new driver will send it if supported by fw.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.551f40ee2de3.I3e32a5d5c9aa13cbb0e599bef630cdb8e3b031c4@changeid
New MCC response versions expose puncturing support directly in the
regulatory capability flags. Propagate that information from NVM MCC
parsing to MLD MCC handling and fall back to legacy FM/WH MCC-specific
policy when puncturing status is unknown.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.47d1389fa134.I5c7921d6e3c065e3962c5927991498c2d277fd8f@changeid
