<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/broadcom, branch v6.1.124</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.124</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.124'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-12-14T18:54:44+00:00</updated>
<entry>
<title>wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()</title>
<updated>2024-12-14T18:54:44+00:00</updated>
<author>
<name>Norbert van Bolhuis</name>
<email>nvbolhuis@gmail.com</email>
</author>
<published>2024-11-07T13:28:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=67a25ea28f8ec1da8894f2f115d01d3becf67dc7'/>
<id>urn:sha1:67a25ea28f8ec1da8894f2f115d01d3becf67dc7</id>
<content type='text'>
[ Upstream commit 857282b819cbaa0675aaab1e7542e2c0579f52d7 ]

This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.

The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) &gt;&gt; 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.

The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory.

Signed-off-by: Norbert van Bolhuis &lt;nvbolhuis@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://patch.msgid.link/20241107132903.13513-1-nvbolhuis@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: release 'root' node in all execution paths</title>
<updated>2024-12-14T18:54:01+00:00</updated>
<author>
<name>Javier Carrasco</name>
<email>javier.carrasco.cruz@gmail.com</email>
</author>
<published>2024-10-30T17:34:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7e696b979061de3fc482b01b343d2d0fd1248900'/>
<id>urn:sha1:7e696b979061de3fc482b01b343d2d0fd1248900</id>
<content type='text'>
commit 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d upstream.

The fixed patch introduced an additional condition to enter the scope
where the 'root' device_node is released (!settings-&gt;board_type,
currently 'err'), which avoid decrementing the refcount with a call to
of_node_put() if that second condition is not satisfied.

Move the call to of_node_put() to the point where 'root' is no longer
required to avoid leaking the resource if err is not zero.

Cc: stable@vger.kernel.org
Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
Signed-off-by: Javier Carrasco &lt;javier.carrasco.cruz@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://patch.msgid.link/20241030-brcmfmac-of-cleanup-v1-1-0b90eefb4279@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcm80211: BRCM_TRACING should depend on TRACING</title>
<updated>2024-11-08T15:26:40+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2024-09-24T12:09:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a419868e8e4a6d8e57d8c5753c0458c52a5a8589'/>
<id>urn:sha1:a419868e8e4a6d8e57d8c5753c0458c52a5a8589</id>
<content type='text'>
[ Upstream commit b73b2069528f90ec49d5fa1010a759baa2c2be05 ]

When tracing is disabled, there is no point in asking the user about
enabling Broadcom wireless device tracing.

Fixes: f5c4f10852d42012 ("brcm80211: Allow trace support to be enabled separately from debug")
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://patch.msgid.link/81a29b15eaacc1ac1fb421bdace9ac0c3385f40f.1727179742.git.geert@linux-m68k.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmsmac: advertise MFP_CAPABLE to enable WPA3</title>
<updated>2024-09-12T09:10:20+00:00</updated>
<author>
<name>Arend van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2024-06-17T12:26:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f67db18eff1bfa9d909967d24858dfa99f3dd5af'/>
<id>urn:sha1:f67db18eff1bfa9d909967d24858dfa99f3dd5af</id>
<content type='text'>
[ Upstream commit dbb5265a5d7cca1cdba7736dba313ab7d07bc19d ]

After being asked about support for WPA3 for BCM43224 chipset it
was found that all it takes is setting the MFP_CAPABLE flag and
mac80211 will take care of all that is needed [1].

Link: https://lore.kernel.org/linux-wireless/20200526155909.5807-2-Larry.Finger@lwfinger.net/ [1]
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Tested-by: Reijer Boekhoff &lt;reijerboekhoff@protonmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://patch.msgid.link/20240617122609.349582-1-arend.vanspriel@broadcom.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmsmac: LCN PHY code is used for BCM4313 2G-only device</title>
<updated>2024-08-03T06:49:03+00:00</updated>
<author>
<name>Samasth Norway Ananda</name>
<email>samasth.norway.ananda@oracle.com</email>
</author>
<published>2024-05-09T23:10:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0216644f28600ff2af2599c275e3594ff852b441'/>
<id>urn:sha1:0216644f28600ff2af2599c275e3594ff852b441</id>
<content type='text'>
[ Upstream commit c636fa85feb450ca414a10010ed05361a73c93a6 ]

The band_idx variable in the function wlc_lcnphy_tx_iqlo_cal() will
never be set to 1 as BCM4313 is the only device for which the LCN PHY
code is used. This is a 2G-only device.

Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Samasth Norway Ananda &lt;samasth.norway.ananda@oracle.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20240509231037.2014109-1-samasth.norway.ananda@oracle.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: pcie: handle randbuf allocation failure</title>
<updated>2024-06-12T09:03:07+00:00</updated>
<author>
<name>Duoming Zhou</name>
<email>duoming@zju.edu.cn</email>
</author>
<published>2024-03-06T14:04:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0eb2c0528e232b3c32cde9d5e1c9f80ba2996e49'/>
<id>urn:sha1:0eb2c0528e232b3c32cde9d5e1c9f80ba2996e49</id>
<content type='text'>
[ Upstream commit 316f790ebcf94bdf59f794b7cdea4068dc676d4c ]

The kzalloc() in brcmf_pcie_download_fw_nvram() will return null
if the physical memory has run out. As a result, if we use
get_random_bytes() to generate random bytes in the randbuf, the
null pointer dereference bug will happen.

In order to prevent allocation failure, this patch adds a separate
function using buffer on kernel stack to generate random bytes in
the randbuf, which could prevent the kernel stack from overflow.

Fixes: 91918ce88d9f ("wifi: brcmfmac: pcie: Provide a buffer of random bytes to the device")
Suggested-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Duoming Zhou &lt;duoming@zju.edu.cn&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20240306140437.18177-1-duoming@zju.edu.cn
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: Add DMI nvram filename quirk for ACEPC W5 Pro</title>
<updated>2024-04-13T11:04:57+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2024-02-16T21:36:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ead0a04a7f3dc1b475759599b31f450fa64ad3d'/>
<id>urn:sha1:8ead0a04a7f3dc1b475759599b31f450fa64ad3d</id>
<content type='text'>
[ Upstream commit 32167707aa5e7ae4b160c18be79d85a7b4fdfcfb ]

The ACEPC W5 Pro HDMI stick contains quite generic names in the sys_vendor
and product_name DMI strings, without this patch brcmfmac will try to load:
"brcmfmac43455-sdio.$(DEFAULT_STRING)-$(DEFAULT_STRING).txt" as nvram file
which is both too generic and messy with the $ symbols in the name.

The ACEPC W5 Pro uses the same Ampak AP6255 module as the ACEPC T8
and the nvram for the T8 is already in linux-firmware, so point the new
DMI nvram filename quirk to the T8 nvram file.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20240216213649.251718-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach</title>
<updated>2024-04-03T13:19:23+00:00</updated>
<author>
<name>Zheng Wang</name>
<email>zyytlz.wz@163.com</email>
</author>
<published>2024-01-07T07:25:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b812f706fd7090be74812101114a0e165b36744'/>
<id>urn:sha1:0b812f706fd7090be74812101114a0e165b36744</id>
<content type='text'>
[ Upstream commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78 ]

This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:

-&gt;brcmf_usb_probe
  -&gt;brcmf_usb_probe_cb
    -&gt;brcmf_attach
      -&gt;brcmf_bus_started
        -&gt;brcmf_cfg80211_attach
          -&gt;wl_init_priv
            -&gt;brcmf_init_escan
              -&gt;INIT_WORK(&amp;cfg-&gt;escan_timeout_work,
		  brcmf_cfg80211_escan_timeout_worker);

If we disconnect the USB by hotplug, it will call
brcmf_usb_disconnect to make cleanup. The invoking chain is :

brcmf_usb_disconnect
  -&gt;brcmf_usb_disconnect_cb
    -&gt;brcmf_detach
      -&gt;brcmf_cfg80211_detach
        -&gt;kfree(cfg);

While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.

Fix it by deleting the timer and canceling the worker in
brcmf_cfg80211_detach.

Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.")
Signed-off-by: Zheng Wang &lt;zyytlz.wz@163.com&gt;
Cc: stable@vger.kernel.org
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20240107072504.392713-1-arend.vanspriel@broadcom.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmsmac: avoid function pointer casts</title>
<updated>2024-03-26T22:20:36+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-02-13T10:05:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=093cec79f0bbbe59e2ac14e37709d1d094351954'/>
<id>urn:sha1:093cec79f0bbbe59e2ac14e37709d1d094351954</id>
<content type='text'>
[ Upstream commit e1ea6db35fc3ba5ff063f097385e9f7a88c25356 ]

An old cleanup went a little too far and causes a warning with clang-16
and higher as it breaks control flow integrity (KCFI) rules:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c:64:34: error: cast from 'void (*)(struct brcms_phy *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
   64 |                         brcms_init_timer(physhim-&gt;wl, (void (*)(void *))fn,
      |                                                       ^~~~~~~~~~~~~~~~~~~~

Change this one instance back to passing a void pointer so it can be
used with the timer callback interface.

Fixes: d89a4c80601d ("staging: brcm80211: removed void * from softmac phy")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20240213100548.457854-1-arnd@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: b43: Disable QoS for bcm4331</title>
<updated>2024-03-26T22:20:30+00:00</updated>
<author>
<name>Rahul Rameshbabu</name>
<email>sergeantsagara@protonmail.com</email>
</author>
<published>2023-12-31T05:03:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8dd353a1a914721558d42d5bfaf5d6a30adafa1'/>
<id>urn:sha1:b8dd353a1a914721558d42d5bfaf5d6a30adafa1</id>
<content type='text'>
[ Upstream commit 09795bded2e725443fe4a4803cae2079cdaf7b26 ]

bcm4331 seems to not function correctly with QoS support. This may be due
to issues with currently available firmware or potentially a device
specific issue.

When queues that are not of the default "best effort" priority are
selected, traffic appears to not transmit out of the hardware while no
errors are returned. This behavior is present among all the other priority
queues: video, voice, and background. While this can be worked around by
setting a kernel parameter, the default behavior is problematic for most
users and may be difficult to debug. This patch offers a working out-of-box
experience for bcm4331 users.

Log of the issue (using ssh low-priority traffic as an example):
    ssh -T -vvvv git@github.com
    OpenSSH_9.6p1, OpenSSL 3.0.12 24 Oct 2023
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug2: checking match for 'host * exec "/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7sh1i8js8w-gnupg-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye &gt;/dev/null 2&gt;&amp;1'"' host github.com originally github.com
    debug3: /etc/ssh/ssh_config line 5: matched 'host "github.com"'
    debug1: Executing command: '/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7sh1i8js8w-gnupg-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye &gt;/dev/null 2&gt;&amp;1''
    debug3: command returned status 0
    debug3: /etc/ssh/ssh_config line 5: matched 'exec "/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0r"'
    debug2: match found
    debug1: /etc/ssh/ssh_config line 9: Applying options for *
    debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -&gt; '/home/binary-eater/.ssh/known_hosts'
    debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -&gt; '/home/binary-eater/.ssh/known_hosts2'
    debug2: resolving "github.com" port 22
    debug3: resolve_host: lookup github.com:22
    debug3: channel_clear_timeouts: clearing
    debug3: ssh_connect_direct: entering
    debug1: Connecting to github.com [192.30.255.113] port 22.
    debug3: set_sock_tos: set socket 3 IP_TOS 0x48

Fixes: e6f5b934fba8 ("b43: Add QOS support")
Signed-off-by: Rahul Rameshbabu &lt;sergeantsagara@protonmail.com&gt;
Reviewed-by: Julian Calaby &lt;julian.calaby@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://msgid.link/20231231050300.122806-5-sergeantsagara@protonmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
