summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-12net: mdio: realtek-rtl9300: Make otto_emdio_read_cmd() genericMarkus Stockhausen
The otto_emdio_read_cmd() helper still uses RTL9300 specific properties. This cannot be made generic as the I/O register has different layouts for the different SoCs. E.g. - RTL930x: data in bits 31-16, data out bits 15-0 - RTL931x: data in bits 15-0, data out bits 31-16 Add a mask parameter to the function signature and fill it properly in the callers. As the masks will always have bits set from constant defines, there is no need for a consistency check. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mdio: realtek-rtl9300: Add prefix to register field definesMarkus Stockhausen
The current Realtek Otto MDIO driver has some define leftovers without a SoC prefix. When adding new devices there will be an overlap for some of them. Sort this out as follows: - PHY_CTRL_CMD/PHY_CTRL_MMD_DEVAD/PHY_CTRL_MMD_REG are common for all series. Leave them as is but move them into a separate block. - Add RTL9300 prefix to all other defines and adapt the callers. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12dt-bindings: net: realtek,rtl9301-mdio: Add RTL931x seriesMarkus Stockhausen
The 10G Realtek Otto switches are divided into two series - Longan: RTL930x up to 28 ports - Mango : RTL931x up to 56 ports The Mango based devices have 3 different SoCs RTL9311, RTL9312 and RTL9313. The MDIO controller of these switches works like the existing RTL930x logic but has different characteristics and different registers. Add new compatibles in the device tree. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-2-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge tag 'pinctrl-v7.1-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Two fixes for the mcp23s08 driver. - Revert an earlier fix to the AMD pin controller that was all wrong. A proper fix is being developed. * tag 'pinctrl-v7.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: Revert "pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11" pinctrl: mcp23s08: Read spi-present-mask as u8 not u32 pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init
2026-06-12Merge branch 'avoid-mistaken-parent-class-deactivation-during-peek'Jakub Kicinski
Victor Nogueira says: ==================== Avoid mistaken parent class deactivation during peek Several qdiscs (fq_codel, codel and dualpi2) may drop packets while peeking at their queue. When that happens they call qdisc_tree_reduce_backlog() to notify the parent of the backlog/qlen change. The problem is that they do so *before* reincrementing the qlen that peek had temporarily decremented. If the qlen momentarily drops to zero while peek still has an skb to return, qdisc_tree_reduce_backlog() ends up invoking the parent's qlen_notify() callback even though the child is not actually empty. The parent then deactivates the class, while the child still holds a packet. For parents such as QFQ this desync corrupts the active class list and leads to wild memory accesses and NULL pointer dereferences (see the per-patch splats). For HFSC it might lead to stalls [1]. Fix all three qdiscs the same way: only call qdisc_tree_reduce_backlog() once the qlen has been restored, so the parent never observes a transient empty child during peek. Patch 1 fixes this for fq_codel, patch 2 for codel, patch 3 for dualpi2 and patch 4 adds test cases for these 3 setups. Note: Patch 1 is one of two fixes for the stall reported in [1]; the companion fix is "net/sched: sch_hfsc: Don't make class passive twice", sent separately. Note2: A possible cleaner fix is to create a new helper function for peek that only calls qdisc_tree_reduce_backlog after reincrementing the qlen. This would be called from the 3 vulnerable qdiscs, however we thought this might make it harder for backporting so, if people agree, we can submit this cleaner version to net-next after this one is merged. [1] https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ ==================== Link: https://patch.msgid.link/20260610192855.3121513-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/tc-testing: Verify child qdisc will not mistakenly deactivate QFQ ↵Victor Nogueira
parent Create 3 test cases: - Verify fq_codel won't mistakenly deactivate QFQ parent class during peek - Verify codel won't mistakenly deactivate QFQ parent class during peek - Verify dualpi2 won't mistakenly deactivate QFQ parent class during peek Verify that these 3 qdiscs (fq_codel, codel, dualpi2) will not call qdisc_tree_reduce_backlog with an incorrect qlen (0) during peek and mistakenly deactivate a parent class. Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-5-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_dualpi2: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever dualpi2 drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though dualpi2 still has 1 packet on the queue and, thus, mistakenly deactivates the parent's class which leads to a null-ptr-deref: [ 101.427314][ T599] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] SMP KASAN NOPTI [ 101.427755][ T599] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 101.428048][ T599] CPU: 2 UID: 0 PID: 599 Comm: ping Not tainted 7.1.0-rc5-00284-gbce53c430ed7 #102 PREEMPT(full) [ 101.428400][ T599] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 101.428608][ T599] RIP: 0010:qfq_dequeue (net/sched/sch_qfq.c:1150) sch_qfq [ 101.428821][ T599] Code: 00 fc ff df 80 3c 02 00 0f 85 46 0c 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 2d 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b All code [ 101.429348][ T599] RSP: 0018:ffff8881110df4f0 EFLAGS: 00010216 [ 101.429541][ T599] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 101.429763][ T599] RDX: 0000000000000009 RSI: 00000024c0000000 RDI: ffff88811436c2b0 [ 101.429985][ T599] RBP: ffff88811436c000 R08: ffff88811436c280 R09: 1ffff11021277523 [ 101.430206][ T599] R10: 1ffff11021277526 R11: 1ffff11021277527 R12: 00000024c0000000 [ 101.430423][ T599] R13: ffff88811436c2b8 R14: 0000000000000048 R15: 0000000020000000 [ 101.430642][ T599] FS: 00007f61813e1c40(0000) GS:ffff8881691ef000(0000) knlGS:0000000000000000 [ 101.430913][ T599] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.431100][ T599] CR2: 00005651650850a8 CR3: 000000010ca0b000 CR4: 0000000000750ef0 [ 101.431320][ T599] PKRU: 55555554 [ 101.431433][ T599] Call Trace: [ 101.431544][ T599] <TASK> [ 101.431628][ T599] __qdisc_run (net/sched/sch_generic.c:322 net/sched/sch_generic.c:427 net/sched/sch_generic.c:445) [ 101.431792][ T599] ? dev_qdisc_enqueue (./include/trace/events/qdisc.h:49 (discriminator 22) net/core/dev.c:4176 (discriminator 22)) [ 101.431941][ T599] __dev_queue_xmit (./include/net/pkt_sched.h:120 ./include/net/pkt_sched.h:117 net/core/dev.c:4292 net/core/dev.c:4831) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc") Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever fq_codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though fq_codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a recent report [1] and a wild memory access in qfq: [ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full) [ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216 [ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000 [ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000 [ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024 [ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000 [ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578 [ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000 [ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0 [ 29.376103][ T360] PKRU: 55555554 [ 29.376258][ T360] Call Trace: [ 29.376401][ T360] <TASK> ... [ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057) [ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. [1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Reported-by: Anirudh Gupta <anirudhrudr@gmail.com> Closes: https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Tested-by: Anirudh Gupta <anirudhrudr@gmail.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'ipv6-mcast-annotate-data-races-in-proc-net-igmp6'Jakub Kicinski
Yuyang Huang says: ==================== ipv6: mcast: annotate data races in /proc/net/igmp6 /proc/net/igmp6 walks IPv6 multicast memberships under RCU without holding idev->mc_lock, taking a lockless snapshot of two fields that writers update under the lock: mca_flags and mca_work.timer.expires. Patch 1 adds WRITE_ONCE() to all mca_flags update sites and READ_ONCE() to the procfs reader. Patch 2 does the same for the timer.expires read in the procfs path. ==================== Link: https://patch.msgid.link/20260609081113.7613-1-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: mcast: annotate igmp6 timer expiry raceYuyang Huang
/proc/net/igmp6 walks IPv6 multicast memberships under RCU and reads mca_work.timer.expires to print the remaining multicast timer. The delayed-work timer can be updated concurrently. Annotate the intentional lockless procfs snapshot with READ_ONCE(). Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609081113.7613-3-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: mcast: annotate data-races around mca_flagsYuyang Huang
/proc/net/igmp6 walks IPv6 multicast memberships under RCU and prints mca_flags without holding idev->mc_lock. The multicast paths update the field while holding idev->mc_lock. Annotate this intentional lockless snapshot with READ_ONCE() and the matching writers with WRITE_ONCE(). Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609081113.7613-2-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'rxrpc-miscellaneous-fixes'Jakub Kicinski
David Howells says: ==================== rxrpc: Miscellaneous fixes Here are some miscellaneous AF_RXRPC fixes: (1) Make sure rxrpc_verify_data() allocates a buffer, even if the DATA packet being looked at is zero length to avoid potential NULL-pointer exceptions. (2) Don't move an OOB message (e.g. an RxGK CHALLENGE) off the receive queue onto the pending queue in recvmsg() if MSG_PEEK is specified. (3) Fix a potential UAF in rxgk_issue_challenge() in which a tracepoint refers to memory just freed by a different pointer. (4) Fix afs net namespace teardown to cancel the incoming call preallocation charger before we disable listening (which will delete the preallocation queue). (5) Fix rxrpc_kernel_charge_accept() to use the socket mutex to defend against listen(0)/shutdown simultaneously deleting the preallocation queue. ==================== Link: https://patch.msgid.link/20260609140911.838677-1-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: serialize kernel accept preallocation with socket teardownLi Daming
rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog. Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Li Daming <d4n.for.sec@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12afs: Fix netns teardown to cancel the preallocation chargerDavid Howells
Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review). Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Simon Horman <horms@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> cc: Li Daming <d4n.for.sec@gmail.com> cc: Ren Wei <n05ec@lzu.edu.cn> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: Fix UAF in rxgk_issue_challenge()David Howells
Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: Don't move a peeked OOB message onto the pending queueHyunwoo Kim
rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: rxrpc_verify_data ensure rx_dec_buffer allocJeffrey Altman
rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the rxrpc_call.rx_dec_buffer is unallocated and assumes that upon successful return that rx_dec_buffer must be allocated. However, rxrpc_verify_data() does not request an allocation if the rxrpc_skb_priv.len is zero. In addition, failure to allocate rx_dec_buffer will result in a call to skb_copy_bits() with a NULL destination which can trigger a NULL pointer dereference. To prevent these issues rxrpc_verify_data() is modified to always attempt to allocate the rxrpc_call.rx_dec_buffer if it is NULL. This issue was identified with assistance of a private sashiko instance. Fixes: d2bc90cf6c75cb ("rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg") Reported-by: Simon Horman <simon.horman@redhat.com> Signed-off-by: Jeffrey Altman <jaltman@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Jiayuan Chen <jiayuan.chen@linux.dev> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'net-remove-tls_toe'Jakub Kicinski
Sabrina Dubroca says: ==================== net: remove tls_toe This series removes the tls_toe feature, its single user (chtls), and cleans up the EXPORT_SYMBOL()s that no other module requires. Driver changes only compile-tested. ==================== Link: https://patch.msgid.link/cover.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: remove some unused EXPORT_SYMBOL()sSabrina Dubroca
chtls was using a lot of symbols that no other module requires. Remove those EXPORT_SYMBOL()s. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/d124db74f6f0838b652f0ee4b4530964f3cf8d49.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12tls: remove tls_toe and the related driverSabrina Dubroca
The tls_toe feature and its single user (chelsio chtls) have been unmaintained for multiple years. It also hooks into the core of the TCP implementation, and bypasses most of the networking stack. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/1f30e73275c07bf879f547589872d0916025a52e.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ethtool: tsconfig: always take rtnl_lockJakub Kicinski
mlx5 throws ASSERT_RTNL() warnings on timestamp config, because it tries to update features. mlx5e_hwtstamp_set() calls netdev_update_features(). I missed this while grepping the drivers because tsconfig goes through ndo_hwtstamp_set/get, not ethtool ops, even tho the new uAPI is in ethtool Netlink. We could add a dedicated opt out bit for mlx5, but NDOs were not supposed to be part of the ethtool locking conversion in the first place. The mlx5 features update is related to the "compressed CQE" format which lacks timestamp, apparently. See commit c0194e2d0ef0 ("net/mlx5e: Disable rxhash when CQE compress is enabled"). Fixes: f9a3e05114b8 ("net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260611200355.2020663-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ip_tunnel: annotate data-races around t->err_count and t->err_timeEric Dumazet
ip_tunnel_xmit() runs locklessly (dev->lltx == true). ipgre_err() and ipip_err() also run locklessly. We need to add READ_ONCE() and WRITE_ONCE() annotations around t->err_count and t->err_time. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260611165247.2710257-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12virtio_net: do not allow tunnel csum offload for non GSO packetsPaolo Abeni
Fiona reports broken connectivity for virtio net setup using UDP tunnel inside the guest and NIC with not UDP tunnel TSO support in the host. Currently the virtio_net driver exposes csum offload for UDP-tunneled, TCP non GSO packets. Such packet reach the host as CSUM_PARTIAL ones with the 'encapsulation' flag cleared, as the virtio specification do not support this specific kind of offload. HW NICs with UDP tunnel TSO support - and those drivers directly accessing skb->csum_start/csum_offset - are still capable of computing the needed csum correctly, but otherwise the packets reach the wire with bad csum on both the inner and outer transport header. Address the issue explicitly disabling csum offload for UDP tunneled, non GSO packets via the ndo_features_check op. Fixes: 56a06bd40fab ("virtio_net: enable gso over UDP tunnel support.") Reported-by: Fiona Ebner <f.ebner@proxmox.com> Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7627 Tested-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Gabriel Goller <g.goller@proxmox.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Gabriel Goller <g.goller@proxmox.com> Tested-by: Gabriel Goller <g.goller@proxmox.com> Link: https://patch.msgid.link/6c3b6c47fb05c100f384630dc48f3975cf37b67a.1781195144.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: atm: reject out-of-range traffic classes in QoS validationZhengchuan Liang
Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/58f02c6f73d9818fd5d2022e1116759fdde6116b.1780965530.git.zcliangcn@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: hsr: simplify fill_last_seq_nrs()Yury Norov
The function checks the HSR_PT_SLAVE_A and HSR_PT_SLAVE_B bitmaps for emptiness right before calling find_last_bit(). This pass may be avoided, because if the bitmap is empty, the find_last_bit() returns >= HSR_SEQ_BLOCK_SIZE Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: Felix Maurer <fmaurer@redhat.com> Link: https://patch.msgid.link/20260609171545.1051322-1-ynorov@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12tcp: clear sock_ops cb flags before force-closing a child socketSechang Lim
A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: <IRQ> tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 </IRQ> The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too. Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev> Fixes: d44874910a26 ("bpf: Add BPF_SOCK_OPS_STATE_CB") Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260611092923.1895982-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: ethernet: sis900: correct CONFIG_VLAN_8021Q macro name in commentEthan Nelson-Moore
A comment in drivers/net/ethernet/sis/sis900.h incorrectly refers to CONFIG_VLAN_802_1Q instead of CONFIG_VLAN_8021Q. Correct it. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260609175656.20574-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12docs: net: fix minor issues with XDP metadata docsJakub Kicinski
Minor updates to the XDP metadata documentation: - s/union/struct/ for xsk_tx_metadata - document nested request and completion metadata fields - point capability queries at the xsk-features attribute - fix grammar in the XDP RX metadata guide - typos Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/20260609201224.1191391-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12bnxt: fix head underflow on XDP head-growJoe Damato
The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue. Fixes: f6974b4c2d8e ("bnxt_en: Fix page pool logic for page size >= 64K") Signed-off-by: Joe Damato <joe@dama.to> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260609204458.2237787-2-joe@dama.to Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: stmmac: xgmac2: disable RBUE in default RX interrupt maskNazim Amirul
Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260609121703.9736-1-muhammad.nazim.amirul.nazle.asmade@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge tag 'drm-fixes-2026-06-13' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Looks like it's settled down a bit more thankfully. Small changes across the board, amdgpu/xe leading with some colorop changes in the core/amd. Otherwise some misc driver fixes. colorop: - make lut interpolation mutable - track colorop updates correctly amdgpu: - UserQ fix - Userptr fix - MCCS freesync fix - track colorop changes correctly amdkfd: - Fix an event information leak - Events bounds check fix - Trap cleanup fix i915: - Check supported link rates DPCD read - Fix phys BO pread/pwrite with offset xe: - fix oops in suspend/shutdown without display - RAS fixes - Use HW_ERR prefix in log - include all registered queues in TLB invalidation - Fix refcount leak in xe_range_tree in error paths - fix job timeout recovery for unstarted jobs and kernel queues amdxdna: - fix possible leak of mm_struct ivpu: - fix integer truncation vc4: - fix leak in krealloc() error handling virtio: - fix dma_fence ref-count leak" * tag 'drm-fixes-2026-06-13' of https://gitlab.freedesktop.org/drm/kernel: (24 commits) accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() drm/xe: fix job timeout recovery for unstarted jobs and kernel queues drm/xe: fix refcount leak in xe_range_fence_insert() drm/xe: include all registered queues in TLB invalidation drm/xe/hw_error: Use HW_ERR prefix in log drm/xe/drm_ras: Add per node cleanup action drm/xe/drm_ras: Make counter allocation drm managed drm/xe/display: fix oops in suspend/shutdown without display drm/amd/display: use plane color_mgmt_changed to track colorop changes drm/atomic: track individual colorop updates drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable drm/colorop: Remove read-only comments from interpolation fields drm/i915/gem: Fix phys BO pread/pwrite with offset drm/vc4: fix krealloc() memory leak drm/virtio: Fix driver removal with disabled KMS drm/i915/edp: Check supported link rates DPCD read accel/ivpu: Fix signed integer truncation in IPC receive drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() drm/amd/display: Consult MCCS FreeSync cap only if requested & supported drm/amdkfd: Unwind debug trap enable on copy_to_user failure ...
2026-06-12handshake: Require admin permission for DONE commandChuck Lever
ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENL_ADMIN_PERM; DONE has no privilege check at all. The fd-lookup in handshake_nl_done_doit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKE_A_DONE_STATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260609141831.90694-1-cel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'selftests-xsk-simplify-umem-setup'Jakub Kicinski
Tushar Vyavahare says: ==================== selftests/xsk: simplify UMEM setup This series simplifies UMEM handling in selftests/xsk. It centralizes UMEM property setup through helpers, moves UMEM ownership from ifobject to socket-owned state, and normalizes umem_size/mmap_size usage across the touched paths. ==================== Link: https://patch.msgid.link/20260608130938.958793-1-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Introduce mmap_size in umem structTushar Vyavahare
UMEM teardown currently recomputes the munmap() length from frame geometry, shared-UMEM adjustment, and hugepage rounding. This duplicates setup-time logic in cleanup and relies on re-deriving the mapping size instead of using the size originally established for the mapping. Store the final mapping length in xsk_umem_info as mmap_size when the UMEM mapping is created, and use that value during teardown. Also join the RX worker thread before cleanup in the single-thread path. This establishes synchronization before reading umem->mmap_size in teardown and avoids a potential visibility race. This removes duplicated size arithmetic in cleanup and makes munmap() use the canonical mapping size recorded at setup time. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-5-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Use umem_size() helper consistentlyTushar Vyavahare
Replace remaining open-coded `umem->num_frames * umem->frame_size` calculations in test_xsk.c with the existing `umem_size()` helper. This keeps UMEM size computation centralized, avoids duplicated arithmetic, and improves readability with no intended behavior change. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-4-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Move UMEM state from ifobject to xsk_socket_infoTushar Vyavahare
Move UMEM ownership from ifobject to xsk_socket_info and access it through xsk->umem. Allocate one shared umem_real in ifobject_create() and let all sockets reference it through xsk->umem, while keeping ownership in xsk_arr[0]. Keep the existing goto-based error path in ifobject_create() and free the allocation once in ifobject_delete(). Reset the existing umem_real in __test_spec_init() with memset() instead of reallocating it. Preserve shared-UMEM behavior by copying RX UMEM state into a TX-local UMEM state in thread_common_ops_tx() and reset base_addr/next_buffer before TX socket configuration. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Link: https://patch.msgid.link/20260608130938.958793-3-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Introduce helpers for setting UMEM propertiesTushar Vyavahare
UMEM properties are set via open-coded field assignments in multiple test paths, which makes updates noisy and error-prone. Introduce two helpers to set UMEM properties through a single interface. This keeps setup logic consistent across tests and makes future refactoring simpler. No functional behavior change is intended. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-2-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-13pinctrl: Match DT helper typesRob Herring (Arm)
The affected pinctrl drivers either check for the presence of a standard property or read a property documented with an 8-bit cell encoding. Using boolean or u32 helpers for those cases disagrees with the binding. Use a presence helper for "gpio-ranges" and read "microchip,spi-present-mask" with the u8 helper documented by the binding. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-12dt-bindings: embedded-controller: Add Qualcomm reference device EC descriptionMaya Matuszczyk
Add description for the EC firmware running on Hamoa/Purwa and Glymur reference devices. Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20260511-add-driver-for-ec-v9-1-e5437c39b7f8@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-12dt-bindings: pwm: add IPQ6018 bindingDevi Priya
DT binding for the PWM block in Qualcomm IPQ6018 SoC. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Co-developed-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://patch.msgid.link/20260406-ipq-pwm-v21-1-6ed1e868e4c2@outlook.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-12selftests: tc: act_pedit: require matching IPv4 L4 protocolVictor Nogueira
Add a tdc test that checks the act_pedit extended L4 header mode does not edit a packet whose IPv4 protocol does not match the selected transport header. The test installs an ingress pedit rule that sets the UDP destination port, then injects a TCP packet with dport 2222. The UDP and TCP destination ports sit at the same L4 offset, so a buggy kernel rewrites the TCP dport. A second flower filter matches TCP dport 2222 and drops the packet through an indexed gact action; the test then verifies via JSON that this action saw exactly one packet, i.e. the dport was left untouched and still matched 2222. Signed-off-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: act_pedit: require matching IPv4 L4 protocolSamuel Moelius
The extended IPv4 L4 header mode in act_pedit can select TCP or UDP header fields without confirming that the IPv4 protocol field matches the selected transport header. That lets a rule written for TCP or UDP modify unrelated payload bytes in a packet carrying a different protocol. Verify that the IPv4 header is long enough, that the protocol matches the selected TCP or UDP header, and that the packet is not a non-initial fragment before applying TCP or UDP extended header edits. Cc: stable+noautosel@kernel.org # in real rule sets the match confirms this before calling the action Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-13Merge tag 'drm-misc-next-fixes-2026-06-11' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v7.2: - Fix agp_amd64_probe error propagation. - Require carveout when PASID is not enabled amdxdna. - Clear variable to prevent second unbind in amdxdna. - Add separate Kconfig option for DMABUF_HEAPS_SYSTEM_CC_SHARED. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/c7a9dbb0-a5c8-4e67-904e-1a52b3de9bb4@linux.intel.com
2026-06-12dt-bindings: hwmon: Add Apple System Management Controller hwmon schemaJames Calligeros
Apple Silicon devices integrate a vast array of sensors, monitoring current, power, temperature, and voltage across almost every part of the system. The sensors themselves are all connected to the System Management Controller (SMC). The SMC firmware exposes the data reported by these sensors via its standard FourCC-based key-value API. The SMC is also responsible for monitoring and controlling any fans connected to the system, exposing them in the same way. For reasons known only to Apple, each device exposes its sensors with an almost totally unique set of keys. This is true even for devices which share an SoC. An M1 Mac mini, for example, will report its core temperatures on different keys to an M1 MacBook Pro. Worse still, the SMC does not provide a way to enumerate the available keys at runtime, nor do the keys follow any sort of reasonable or consistent naming rules that could be used to deduce their purpose. We must therefore know which keys are present on any given device, and which function they serve, ahead of time. Add a schema so that we can describe the available sensors for a given Apple Silicon device in the Devicetree. Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Link: https://patch.msgid.link/20251215-macsmc-subdevs-v6-1-0518cb5f28ae@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-13Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warningsRandy Dunlap
Repair the docs build warnings in this file by unindenting the description, adding blank lines, and using `` to quote *arg. WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils] Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils] Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260426232705.422938-1-rdunlap@infradead.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-13power: supply: charger-manager: fix refcount leak in is_full_charged()WenTao Liang
In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference. Cc: stable@vger.kernel.org Fixes: e132fc6bb89b ("power: supply: charger-manager: Make decisions focussed on battery status") Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260611005322.53096-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-12power: supply: core: fix supplied_from allocationsLucas Tsai
If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in __power_supply_populate_supplied_from will overrun supplied_from array. Fixes: f6e0b081fb30 ("power_supply: Populate supplied_from hierarchy from the device tree") Signed-off-by: Lucas Tsai <lucas_tsai@richtek.com> Link: https://patch.msgid.link/20260609114403.3896073-1-lucas_tsai@richtek.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-13Merge tag 'drm-misc-fixes-2026-06-12' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: amd: - track colorop changes correctly amdxdna: - fix possible leak of mm_struct colorop: - make lut interpolation mutable - track colorop updates correctly ivpu: - fix integer truncation vc4: - fix leak in krealloc() error handling virtio: - fix dma_fence ref-count leak Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260612081418.GA17001@2a02-2455-9062-2500-e496-5a17-62ba-545e.dyn6.pyur.net
2026-06-12fbdev: modedb: Fix misaligned fields in the 1920x1080-60 modeSteffen Persvold
The 1920x1080@60 modedb entry has one too many initializers before its sync field: a stray "0" occupies the sync slot, which shifts the remaining values by one field. The entry therefore decodes as sync = 0, vmode = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT (0x3, i.e. FB_VMODE_INTERLACED | FB_VMODE_DOUBLE), and flag = FB_VMODE_NONINTERLACED, instead of the intended sync = positive H/V, vmode = non-interlaced. fb_find_mode() then returns a 1920x1080 mode flagged as interlaced + doublescan with active-low syncs. Drivers that honour var->vmode and var->sync when programming display timing enable doublescan and the wrong sync polarity, corrupting the output. Drop the stray initializer so sync and vmode hold their intended values (positive H/V sync, non-interlaced), matching the adjacent 1920x1200 entry. Fixes: c8902258b2b8 ("fbdev: modedb: Add 1920x1080 at 60 Hz video mode") Cc: stable@vger.kernel.org Signed-off-by: Steffen Persvold <spersvold@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-16 15:15:36 +0000