<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wwan, branch v6.18.21</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-04T12:20:12+00:00</updated>
<entry>
<title>net: wwan: mhi: Add network support for Foxconn T99W760</title>
<updated>2026-03-04T12:20:12+00:00</updated>
<author>
<name>Slark Xiao</name>
<email>slark_xiao@163.com</email>
</author>
<published>2026-01-05T02:26:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fce7f6f63915472d8dd6e9af7b2e3124d124c547'/>
<id>urn:sha1:fce7f6f63915472d8dd6e9af7b2e3124d124c547</id>
<content type='text'>
[ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ]

T99W760 is designed based on Qualcomm SDX35 chip. It use similar
architecture with SDX72/SDX75 chip. So we need to assign initial
link id for this device to make sure network available.

Signed-off-by: Slark Xiao &lt;slark_xiao@163.com&gt;
Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: t7xx: fix potential skb-&gt;frags overflow in RX path</title>
<updated>2026-02-06T15:57:31+00:00</updated>
<author>
<name>Kery Qi</name>
<email>qikeyu2017@gmail.com</email>
</author>
<published>2026-01-22T17:04:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c0fb0f60bc1545c52da61bc6bd4855c1e7814ba'/>
<id>urn:sha1:2c0fb0f60bc1545c52da61bc6bd4855c1e7814ba</id>
<content type='text'>
[ Upstream commit f0813bcd2d9d97fdbdf2efb9532ab03ae92e99e6 ]

When receiving data in the DPMAIF RX path,
the t7xx_dpmaif_set_frag_to_skb() function adds
page fragments to an skb without checking if the number of
fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow
in skb_shinfo(skb)-&gt;frags[] array, corrupting adjacent memory and
potentially causing kernel crashes or other undefined behavior.

This issue was identified through static code analysis by comparing with a
similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76:
fix array overflow on receiving too many fragments for a packet").

The vulnerability could be triggered if the modem firmware sends packets
with excessive fragments. While under normal protocol conditions (MTU 3080
bytes, BAT buffer 3584 bytes),
a single packet should not require additional
fragments, the kernel should not blindly trust firmware behavior.
Malicious, buggy, or compromised firmware could potentially craft packets
with more fragments than the kernel expects.

Fix this by adding a bounds check before calling skb_add_rx_frag() to
ensure nr_frags does not exceed MAX_SKB_FRAGS.

The check must be performed before unmapping to avoid a page leak
and double DMA unmap during device teardown.

Fixes: d642b012df70a ("net: wwan: t7xx: Add data path interface")
Signed-off-by: Kery Qi &lt;qikeyu2017@gmail.com&gt;
Link: https://patch.msgid.link/20260122170401.1986-2-qikeyu2017@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: iosm: Fix memory leak in ipc_mux_deinit()</title>
<updated>2026-01-17T15:35:24+00:00</updated>
<author>
<name>Zilin Guan</name>
<email>zilin@seu.edu.cn</email>
</author>
<published>2025-12-30T07:18:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8181c79757cc9383f9697745d24793555429c888'/>
<id>urn:sha1:8181c79757cc9383f9697745d24793555429c888</id>
<content type='text'>
[ Upstream commit 92e6e0a87f6860a4710f9494f8c704d498ae60f8 ]

Commit 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
allocated memory for pp_qlt in ipc_mux_init() but did not free it in
ipc_mux_deinit(). This results in a memory leak when the driver is
unloaded.

Free the allocated memory in ipc_mux_deinit() to fix the leak.

Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
Co-developed-by: Jianhao Xu &lt;jianhao.xu@seu.edu.cn&gt;
Signed-off-by: Jianhao Xu &lt;jianhao.xu@seu.edu.cn&gt;
Signed-off-by: Zilin Guan &lt;zilin@seu.edu.cn&gt;
Reviewed-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20251230071853.1062223-1-zilin@seu.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: mhi: Keep modem name match with Foxconn T99W640</title>
<updated>2025-11-27T01:04:07+00:00</updated>
<author>
<name>Slark Xiao</name>
<email>slark_xiao@163.com</email>
</author>
<published>2025-11-25T07:09:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4fcb8ab4a09b1855dbfd7062605dd13abd64c086'/>
<id>urn:sha1:4fcb8ab4a09b1855dbfd7062605dd13abd64c086</id>
<content type='text'>
Correct it since M.2 device T99W640 has updated from T99W515.
We need to align it with MHI side otherwise this modem can't
get the network.

Fixes: ae5a34264354 ("bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640")
Signed-off-by: Slark Xiao &lt;slark_xiao@163.com&gt;
Reviewed-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20251125070900.33324-1-slark_xiao@163.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: t7xx: add support for HP DRMR-H01</title>
<updated>2025-10-06T18:10:38+00:00</updated>
<author>
<name>Sammy Hsu</name>
<email>zelda3121@gmail.com</email>
</author>
<published>2025-10-02T02:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=370e98728bda92b1bdffb448d1acdcbe19dadb4c'/>
<id>urn:sha1:370e98728bda92b1bdffb448d1acdcbe19dadb4c</id>
<content type='text'>
add support for HP DRMR-H01 (0x03f0, 0x09c8)

Signed-off-by: Sammy Hsu &lt;sammy.hsu@wnc.com.tw&gt;
Link: https://patch.msgid.link/20251002024841.5979-1-sammy.hsu@wnc.com.tw
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: WQ_PERCPU added to alloc_workqueue users</title>
<updated>2025-09-23T00:40:30+00:00</updated>
<author>
<name>Marco Crivellari</name>
<email>marco.crivellari@suse.com</email>
</author>
<published>2025-09-18T14:24:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=27ce71e1ce81875df72f7698ba27988392bef602'/>
<id>urn:sha1:27ce71e1ce81875df72f7698ba27988392bef602</id>
<content type='text'>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This change adds a new WQ_PERCPU flag at the network subsystem, to explicitly
request the use of the per-CPU behavior. Both flags coexist for one release
cycle to allow callers to transition their calls.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

All existing users have been updated accordingly.

Suggested-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Marco Crivellari &lt;marco.crivellari@suse.com&gt;
Link: https://patch.msgid.link/20250918142427.309519-4-marco.crivellari@suse.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: iosm: use int type to store negative error codes</title>
<updated>2025-08-28T01:17:15+00:00</updated>
<author>
<name>Qianfeng Rong</name>
<email>rongqianfeng@vivo.com</email>
</author>
<published>2025-08-26T13:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f0c88a0d83b26bcfbb3463d3a283bc08007a5ae0'/>
<id>urn:sha1:f0c88a0d83b26bcfbb3463d3a283bc08007a5ae0</id>
<content type='text'>
The 'ret' variable in ipc_pcie_resources_request() either stores '-EBUSY'
directly or holds returns from pci_request_regions() and ipc_acquire_irq().
Storing negative error codes in u32 causes no runtime issues but is
stylistically inconsistent and very ugly.  Change 'ret' from u32 to int
type - this has no runtime impact.

Signed-off-by: Qianfeng Rong &lt;rongqianfeng@vivo.com&gt;
Reviewed-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20250826135021.510767-1-rongqianfeng@vivo.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>relayfs: abolish prev_padding</title>
<updated>2025-07-10T05:57:51+00:00</updated>
<author>
<name>Jason Xing</name>
<email>kernelxing@tencent.com</email>
</author>
<published>2025-06-12T06:11:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2489e958129ff7cbf26a34ee33cdc9ccbd68fe3c'/>
<id>urn:sha1:2489e958129ff7cbf26a34ee33cdc9ccbd68fe3c</id>
<content type='text'>
Patch series "relayfs: misc changes", v5.

The series mostly focuses on the error counters which helps every user
debug their own kernel module.


This patch (of 5):

prev_padding represents the unused space of certain subbuffer.  If the
content of a call of relay_write() exceeds the limit of the remainder of
this subbuffer, it will skip storing in the rest space and record the
start point as buf-&gt;prev_padding in relay_switch_subbuf().  Since the buf
is a per-cpu big buffer, the point of prev_padding as a global value for
the whole buffer instead of a single subbuffer (whose padding info is
stored in buf-&gt;padding[]) seems meaningless from the real use cases, so we
don't bother to record it any more.

Link: https://lkml.kernel.org/r/20250612061201.34272-1-kerneljasonxing@gmail.com
Link: https://lkml.kernel.org/r/20250612061201.34272-2-kerneljasonxing@gmail.com
Signed-off-by: Jason Xing &lt;kernelxing@tencent.com&gt;
Reviewed-by: Yushan Zhou &lt;katrinzhou@tencent.com&gt;
Reviewed-by: Masami Hiramatsu (Google) &lt;mhiramat@kernel.org&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>net: wwan: mhi_wwan_mbim: use correct mux_id for multiplexing</title>
<updated>2025-06-05T10:27:20+00:00</updated>
<author>
<name>Daniele Palmas</name>
<email>dnlplm@gmail.com</email>
</author>
<published>2025-06-03T09:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=501fe52aa908c96f2c9b8d54767938a1a5960354'/>
<id>urn:sha1:501fe52aa908c96f2c9b8d54767938a1a5960354</id>
<content type='text'>
Recent Qualcomm chipsets like SDX72/75 require MBIM sessionId mapping
to muxId in the range (0x70-0x8F) for the PCIe tethered use.

This has been partially addressed by the referenced commit, mapping
the default data call to muxId = 112, but the multiplexed data calls
scenario was not properly considered, mapping sessionId = 1 to muxId
1, while it should have been 113.

Fix this by moving the session_id assignment logic to mhi_mbim_newlink,
in order to map sessionId = n to muxId = n + WDS_BIND_MUX_DATA_PORT_MUX_ID.

Fixes: 65bc58c3dcad ("net: wwan: mhi: make default data link id configurable")
Signed-off-by: Daniele Palmas &lt;dnlplm@gmail.com&gt;
Reviewed-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20250603091204.2802840-1-dnlplm@gmail.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>net: wwan: t7xx: Fix napi rx poll issue</title>
<updated>2025-06-03T08:32:45+00:00</updated>
<author>
<name>Jinjian Song</name>
<email>jinjian.song@fibocom.com</email>
</author>
<published>2025-05-30T03:16:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=905fe0845bb27e4eed2ca27ea06e6c4847f1b2b1'/>
<id>urn:sha1:905fe0845bb27e4eed2ca27ea06e6c4847f1b2b1</id>
<content type='text'>
When driver handles the napi rx polling requests, the netdev might
have been released by the dellink logic triggered by the disconnect
operation on user plane. However, in the logic of processing skb in
polling, an invalid netdev is still being used, which causes a panic.

BUG: kernel NULL pointer dereference, address: 00000000000000f1
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dev_gro_receive+0x3a/0x620
[...]
Call Trace:
 &lt;IRQ&gt;
 ? __die_body+0x68/0xb0
 ? page_fault_oops+0x379/0x3e0
 ? exc_page_fault+0x4f/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]
 ? dev_gro_receive+0x3a/0x620
 napi_gro_receive+0xad/0x170
 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]
 t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]
 net_rx_action+0x103/0x470
 irq_exit_rcu+0x13a/0x310
 sysvec_apic_timer_interrupt+0x56/0x90
 &lt;/IRQ&gt;

Fixes: 5545b7b9f294 ("net: wwan: t7xx: Add NAPI support")
Signed-off-by: Jinjian Song &lt;jinjian.song@fibocom.com&gt;
Link: https://patch.msgid.link/20250530031648.5592-1-jinjian.song@fibocom.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
</feed>
