<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/drivers/net/wireless/intel, branch master</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2026-09-09T11:24:56+00:00</updated>
<entry>
<title>Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git</title>
<updated>2026-09-09T11:24:56+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2026-09-09T11:24:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=79923813bdf1bd0fabdd9a89792738b9b3dc5e93'/>
<id>urn:sha1:79923813bdf1bd0fabdd9a89792738b9b3dc5e93</id>
<content type='text'>
</content>
</entry>
<entry>
<title>treewide: refresh kmalloc_obj() conversions</title>
<updated>2026-09-05T04:37:00+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees+treewide@kernel.org</email>
</author>
<published>2026-09-02T22:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d'/>
<id>urn:sha1:3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d</id>
<content type='text'>
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 &lt;kees+treewide@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: ipw2x00: bound management frame length to the receive buffer</title>
<updated>2026-09-04T08:12:29+00:00</updated>
<author>
<name>Shmulik Cohen</name>
<email>anuk909@gmail.com</email>
</author>
<published>2026-08-12T19:04:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c46cfaf8db42de0806076139fb40744d23041377'/>
<id>urn:sha1:c46cfaf8db42de0806076139fb40744d23041377</id>
<content type='text'>
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 &lt;anuk909@gmail.com&gt;
Link: https://patch.msgid.link/20260812190412.18333-4-anuk909@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: libipw: reject too-short association responses</title>
<updated>2026-09-04T08:12:29+00:00</updated>
<author>
<name>Shmulik Cohen</name>
<email>anuk909@gmail.com</email>
</author>
<published>2026-08-12T19:04:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=adb7118b7d2cfd7e8213c17d7d2829f353017754'/>
<id>urn:sha1:adb7118b7d2cfd7e8213c17d7d2829f353017754</id>
<content type='text'>
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-&gt;len - sizeof(*frame)

stats-&gt;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: 9e8571affd1c ("[PATCH] ieee80211: Add QoS (WME) support to the ieee80211 subsystem")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen &lt;anuk909@gmail.com&gt;
Link: https://patch.msgid.link/20260812190412.18333-3-anuk909@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: libipw: reject too-short beacon and probe responses</title>
<updated>2026-09-04T08:12:29+00:00</updated>
<author>
<name>Shmulik Cohen</name>
<email>anuk909@gmail.com</email>
</author>
<published>2026-08-12T19:04:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5ce5721e8cbe3e80db8f43851cc2a2a92485ef4b'/>
<id>urn:sha1:5ce5721e8cbe3e80db8f43851cc2a2a92485ef4b</id>
<content type='text'>
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-&gt;len - sizeof(*beacon)

stats-&gt;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: b453872c35cf ("[NET] ieee80211 subsystem")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shmulik Cohen &lt;anuk909@gmail.com&gt;
Link: https://patch.msgid.link/20260812190412.18333-2-anuk909@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlegacy: fix broadcast stations deallocation</title>
<updated>2026-09-04T08:06:03+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>stf_xl@wp.pl</email>
</author>
<published>2026-08-20T09:30:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b5526b780f8b297a76030410b96ba29153afb98f'/>
<id>urn:sha1:b5526b780f8b297a76030410b96ba29153afb98f</id>
<content type='text'>
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 &lt;martin-eric.racine+kernel-bugzilla@iki.fi&gt;
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221733
Fixes: c2fd34469d16 ("iwl4965: Fix a memory leak in error handling code of __il4965_up")
Cc: &lt;stable@vger.kernel.org&gt; # 7.1.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Cc: &lt;stable@vger.kernel.org&gt; # 6.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Cc: &lt;stable@vger.kernel.org&gt; # 5.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
Signed-off-by: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Link: https://patch.msgid.link/20260820093059.18779-1-stf_xl@wp.pl
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next</title>
<updated>2026-08-06T19:39:11+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-08-06T19:39:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4fa4977a0d900f936bcae5cd2c510be5554e8dd6'/>
<id>urn:sha1:4fa4977a0d900f936bcae5cd2c510be5554e8dd6</id>
<content type='text'>
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 &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'iwlwifi-next-2026-07-23' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next</title>
<updated>2026-07-28T13:59:46+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2026-07-28T13:59:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=905b418df8af2ca830c2237e029f174911b53415'/>
<id>urn:sha1:905b418df8af2ca830c2237e029f174911b53415</id>
<content type='text'>
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 &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check</title>
<updated>2026-07-28T13:35:37+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>stf_xl@wp.pl</email>
</author>
<published>2026-07-24T09:55:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=57aa1718d5953dd532137d43b696c68545c2e0b3'/>
<id>urn:sha1:57aa1718d5953dd532137d43b696c68545c2e0b3</id>
<content type='text'>
BUG_ON() for il-&gt;num_stations &lt; 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 &lt;stf_xl@wp.pl&gt;
Link: https://patch.msgid.link/20260724095545.33647-1-stf_xl@wp.pl
[clarify commit message wrt. debugfs buffer]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: bump core version for BZ/SC/DR</title>
<updated>2026-07-23T17:26:32+00:00</updated>
<author>
<name>Miri Korenblit</name>
<email>miriam.rachel.korenblit@intel.com</email>
</author>
<published>2026-07-23T11:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4a2610a5a9fcf77eaad82bb030ec77ec5e381db8'/>
<id>urn:sha1:4a2610a5a9fcf77eaad82bb030ec77ec5e381db8</id>
<content type='text'>
Start supporting Core 107 FW on these devices.

Link: https://patch.msgid.link/20260723142324.ed92b1d7f927.I6dd10d2f9a04a36751aea9e238fecfa62fe280a6@changeid
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
</content>
</entry>
</feed>
