* Re: [PATCH net v2] bnxt_en: Handle partially initialized auxiliary devices
From: patchwork-bot+netdevbpf @ 2026-07-17 10:50 UTC (permalink / raw)
To: Ruoyu Wang
Cc: michael.chan, pavan.chebbi, andrew+netdev, davem, edumazet, kuba,
pabeni, jacob.e.keller, andrew.gospodarek, vikas.gupta, netdev,
linux-kernel
In-Reply-To: <20260711163716.3996929-1-ruoyuw560@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Jul 2026 00:37:16 +0800 you wrote:
> bnxt_aux_devices_init() calls auxiliary_device_init() before all fields
> used by bnxt_aux_dev_release() are initialized. After
> auxiliary_device_init() succeeds, later errors must unwind with
> auxiliary_device_uninit(), which invokes the release callback.
>
> The release callback assumes that aux_priv->id, aux_priv->edev,
> edev->net and edev->ulp_tbl are all populated. If allocation fails
> after auxiliary_device_init(), the release path can otherwise dereference
> or clear partially initialized state.
>
> [...]
Here is the summary with links:
- [net,v2] bnxt_en: Handle partially initialized auxiliary devices
https://git.kernel.org/netdev/net/c/1cb8553c02e9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] Add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver
From: Artem Shimko @ 2026-07-17 10:50 UTC (permalink / raw)
To: Maxime Chevallier
Cc: netdev, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zhi Li,
linux-kernel, devicetree
In-Reply-To: <77f1cc14-cc5f-4f32-a972-f0350a60931b@bootlin.com>
Hi Maxime,
I could suggest a couple options for how I should handle the driver:
1. Recognizing that this is a problem with the PCS layer, I can remove
the inversion from the patch
(but add it to my working project as a separate, non-upstream patch).
This way, we'll just leave the delays setting in the driver, which is
fairly common among driver users.
2. Leave the inversion in the driver until some future common
framework solution is developed, and
then adapt this part of the driver to that solution. I'd be happy to
help develop/modify that framework =).
A packet generator could also be added to it.
--
Best regards,
Artem
On Thu, Jul 16, 2026 at 9:11 PM Maxime Chevallier
<maxime.chevallier@bootlin.com> wrote:
>
> Hi Artem,
>
> Please slow down a bit, you need to wait at least 24h between patch
> submissions :
>
> https://docs.kernel.org/process/maintainer-netdev.html
>
> On 7/16/26 19:33, Artem Shimko wrote:
> > Hello,
> >
> > This series adds support for the DAPU Telecom DAP8211R(I) Gigabit
> > Ethernet PHY, commonly used in enterprise and industrial networking
> > applications. The PHY supports 10/100/1000 Mbps operation with RGMII
> > interface and includes features such as IEEE 802.3az Energy Efficient
> > Ethernet, IEEE 1588 SyncE, and an internal packet generator for
> > diagnostics.
> >
> > The driver implements extended register access via indirect addressing
> > (registers 0x1E/0x1F) and provides comprehensive device tree support
> > for RGMII delay configuration. The rx-internal-delay-ps and
> > tx-internal-delay-ps properties allow precise tuning of clock delays
> > in 150 ps steps from 0 to 2250 ps. The optional dapu,tx-inverted-clk
> > flag enables 180-degree TX clock phase shift for boards where signal
> > integrity or MAC requirements necessitate clock inversion.
>
> +Zhi Li
>
> This isn't the first time we see clock inversion being used to overcome
> RGMII timing issues, for setups that have too big of an internal delay,
> see [1].
>
> I'm wondering if we should either reject this on the account that this
> is bad HW design, or embrace that in which case it would probably be
> a good idea to come-up with more generic ways to handle that.
>
> This patch proposes the "dapu,tx-inverted-clk" property, while Zhi Li's
> patch has a dedicated compatible for that (and inversion is on RX, on the
> MAC side)
>
> If clock inversion is a common thing for MAC and PHYs to be able to do,
> should we add some way of representing the RGMII delays that are
> introduced by the HW itself in DT, and let drivers figure-out from that
> if they need to resort to clock inversion to align clk and data correctly ?
>
> Phylib could maybe even provide helpers for that ?
>
> [1] : https://lore.kernel.org/netdev/20260707064159.1299-1-lizhi2@eswincomputing.com/
>
> Maxime
>
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 1/7] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-07-17 10:51 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <93775de437ca4e25bb59b58a3d083dd0@compal.com>
Hi Simon,
After further internal review, we agree this needs to be fixed.
On Jack Wu wrote:
>> [Severity: Medium]
>> Will this break channel index calculation on big-endian systems?
> This driver targets MediaTek T9xx PCIe WWAN modems on x86/ARM64-LE
> platforms only. On little-endian, cpu_to_le32() is a no-op and
> LE32_TO_U32() is a simple cast — no byte-swap occurs. The Kconfig
> enforces depends on PCI && ACPI, effectively restricting to LE
> platforms where this hardware exists.
In v5 we will:
- Remove LE32_TO_U32(cpu_to_le32(...)) and return hw_bits
directly in both mtk_pci_ext_d2h_evt_hw_bits() and
mtk_pci_ext_h2d_evt_hw_bits()
- Remove the custom LE32_TO_U32 macro
Thanks.
寄件者: Wu. JackBB (GSM)
寄件日期: 2026年7月17日 下午 02:25
收件者: Simon Horman
副本: loic.poulain@oss.qualcomm.com; ryazanov.s.a@gmail.com; johannes@sipsolutions.net; andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; wen-zhi.huang@mediatek.com; shi-wei.yeh@mediatek.com; Minano.tseng@mediatek.com; matthias.bgg@gmail.com; angelogioacchino.delregno@collabora.com; corbet@lwn.net; skhan@linuxfoundation.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-mediatek@lists.infradead.org; linux-doc@vger.kernel.org
主旨: RE: [External Mail] Re: [PATCH v4 1/7] net: wwan: t9xx: Add PCIe core
Hi Simon,
> > +static irqreturn_t mtk_pci_irq_msix(int irq, void *data)
> > +{
> > + if (unlikely(!irq_state) ||
> > + unlikely(!((irq_state & GENMASK(priv->irq_cnt - 1, 0)) &
> > + irq_desc->msix_bits)))
> > + return IRQ_NONE;
>
> [Severity: High]
> Does this logic silently drop hardware interrupts when fewer than 32
> vectors are allocated?
No interrupts are dropped. This is the MSI-X merged mode design.
When fewer vectors are allocated, mtk_pci_set_msix_merged() configures
the hardware to merge all interrupt sources into the available vectors.
For example, with irq_cnt=1, the hardware maps ALL sources (including
MHCCIF at hardware bit 28) to vector 0. The MSI-X status register
shows BIT(0), not BIT(28). So irq_desc[0].msix_bits = BIT(0), and
GENMASK(0,0) & BIT(0) & BIT(0) = 1 — the check passes correctly.
The GENMASK filters to allocated vector bits only, then checks if the
current handler's vector is set. This works for both full allocation
(32 vectors, 1:1 mapping) and merged mode (fewer vectors, N:1 mapping).
> > + ret = pci_request_irq(pdev, i, mtk_pci_irq_msix, NULL,
> > + &irq_desc[i], irq_desc[i].name);
>
> [Severity: Medium]
> Could this trigger a -Wformat-security compiler warning?
We will change to pci_request_irq(..., "%s",
irq_desc[i].name) to avoid format string issues.
> > + hw_bits = mtk_pci_ext_h2d_evt_hw_bits(ch);
> > + mtk_pci_write32(mdev, rc_base + MHCCIF_RC2EP_SW_TCHNUM,
> > + ffs(hw_bits) - 1);
>
> [Severity: Medium]
> Will this break channel index calculation on big-endian systems?
This driver targets MediaTek T9xx PCIe WWAN modems on x86/ARM64-LE
platforms only. On little-endian, cpu_to_le32() is a no-op and
LE32_TO_U32() is a simple cast — no byte-swap occurs. The Kconfig
enforces depends on PCI && ACPI, effectively restricting to LE
platforms where this hardware exists.
> [Severity: Medium]
> What happens if the driver attempts to send an unmapped channel?
All callers of mtk_pci_send_ext_evt() pass known-valid channel values
that are mapped in SET_HW_BITS. The is_power_of_2(ch) check at the
top of the function rejects invalid input. The FSM single-thread
design ensures all ext_evt sends go through a controlled path, so
an unmapped channel cannot reach ffs().
> > + priv->ext_reg_base = priv->bar23_addr - ATR_PCIE_REG_TRSL_ADDR;
>
> [Severity: Medium]
> Is it safe to store an out-of-bounds pointer?
This is a standard pattern in PCIe MMIO drivers using Address
Translation Registers (ATR). The modem's internal register space
starts at address 0x0 in its own view, but the host accesses it
through BAR2/3 mapped at offset ATR_PCIE_REG_TRSL_ADDR (0x10000000).
Pre-computing ext_reg_base = bar23_addr - 0x10000000 allows using
modem register addresses directly: ioread32(ext_reg_base + reg_addr).
ext_reg_base is typed as void __iomem *, an opaque cookie for MMIO
access — never dereferenced as a regular pointer. The ioread32/
iowrite32 functions perform platform-specific MMIO access on it.
UBSAN does not flag __iomem arithmetic. This same pattern is used
by other kernel PCIe drivers (e.g., mtk_t7xx).
> > +static void mtk_pci_remove(struct pci_dev *pdev)
> > +{
> > + if (mtk_pci_pldr(mdev)) { ... }
> > + pci_clear_master(pdev);
> > + mtk_pci_free_irq(mdev);
> > + mtk_mhccif_exit(mdev);
>
> [Severity: High]
> Does this sequence result in the device being powered off before
> the OS interrupt handlers and workqueues are synchronized?
The device is not left powered off. mtk_pci_pldr() calls ACPI
PXP._OFF then PXP._ON — the _ON call restores power and brings
the PCIe link back up. After _ON returns, the device is powered
on and BARs are accessible.
The PLDR sequence is: (1) _OFF: power-cycle modem firmware,
(2) msleep for power drain, (3) _ON: restore power and link.
After step 3, the device is live with a fresh firmware state.
Additionally, before PLDR, mtk_pci_mask_irq() disables the MHCCIF
interrupt at hardware level, preventing new interrupts. Between
pci_clear_master and mtk_pci_free_irq, mtk_pci_dev_exit() tears
down FSM and trans_ctrl, ensuring no workqueues remain scheduled.
> > + /* Request a slot reset. */
> > + return PCI_ERS_RESULT_CAN_RECOVER;
>
> [Severity: Medium]
> Will returning PCI_ERS_RESULT_CAN_RECOVER actually abort the slot
> reset?
We will change to PCI_ERS_RESULT_DISCONNECT and update
the comment, since the driver does not currently support AER
recovery.
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] Add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver
From: Artem Shimko @ 2026-07-17 10:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Maxime Chevallier, netdev, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zhi Li,
linux-kernel, devicetree
In-Reply-To: <05bbadc9-95b0-421e-9c5a-8223a891cb5d@lunn.ch>
Hi Andrew,
On Thu, Jul 16, 2026 at 9:32 PM Andrew Lunn <andrew@lunn.ch> wrote:
> Adding to that, there is no version history. How does v3 differ to
> v2.
My apologies, I will fix it.
--
Best regards,
Artem
^ permalink raw reply
* Re: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
From: Greg KH @ 2026-07-17 10:51 UTC (permalink / raw)
To: Zhou, Yun
Cc: sdf.kernel, jirislaby, socketcan, linux-serial, mkl, linux-can,
davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel
In-Reply-To: <87ea3ae8-8196-4f6f-bb03-d139f2f6c806@windriver.com>
On Fri, Jul 17, 2026 at 11:03:18AM +0800, Zhou, Yun wrote:
>
>
> On 7/16/26 15:57, Greg KH wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> > On Thu, Jul 16, 2026 at 02:47:19PM +0800, Yun Zhou wrote:
> > > syzbot reported a circular lock dependency involving tty ldisc_sem and
> > > the networking rtnl_mutex. The full chain is:
> > >
> > > rtnl_mutex --> nft_commit_mutex --> ... --> ep->mtx --> ldisc_sem --> rtnl_mutex
> > >
> > > The last edge (ldisc_sem -> rtnl_mutex) is created because tty line
> > > discipline .open() callbacks (slcan, slip) call register_netdev() which
> > > acquires rtnl_mutex, and .open() runs under ldisc_sem write lock in
> > > tty_set_ldisc().
> > >
> > > Fix by moving the .open() call outside the ldisc_sem write lock. The
> > > ldisc .open() is initialization of the NEW discipline after the old one
> > > has been closed - there is no need for ldisc_sem protection at this
> > > point since:
> > >
> > > - tty_lock is held throughout, preventing concurrent tty_set_ldisc,
> > > hangup, or close
> > > - tty->ldisc is set to NULL during the window, so concurrent readers
> > > (tty_ldisc_ref, tty_ldisc_ref_wait) see NULL and return immediately,
> > > which callers already handle as a hangup condition
> > > - tty buffer data stays queued until the ldisc is installed
> > >
> > > The sequence becomes:
> > > 1. Hold ldisc_sem(write): close old ldisc, set tty->ldisc = NULL
> > > 2. Release ldisc_sem(write)
> > > 3. Call new_ldisc->ops->open() without ldisc_sem
> > > 4. Re-acquire ldisc_sem(write): install new ldisc (or restore old)
> > > 5. Release ldisc_sem(write)
> > >
> > > Reported-by: syzbot+de610eeef174bd59a8a3@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=de610eeef174bd59a8a3
> > > Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> > > ---
> > > drivers/tty/tty_ldisc.c | 17 +++++++++++++++--
> > > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > What commit caused this to be a problem and why have we not seen this in
> > any real-world usages?
> >
>
> The circular dependency has existed for a long time - it just requires
> ldisc_sem -> rtnl_mutex (from slcan/slip registering a netdev in
> .open()) and the reverse path through nft_commit_mutex, epoll, and
> tty_poll back to ldisc_sem.
>
> The recent dev_instance_lock series (5326fefb9fe8 "net: hold instance
> lock around NETDEV_DOWN/GOING_DOWN") increased lockdep's observability
> by adding lock acquisitions in more notifier paths, making it easier for
> lockdep to collect all edges in a single run. It did not create the
> cycle.
>
> We have not seen this in real-world usage because triggering the actual
> deadlock requires 6 unrelated subsystems to contend simultaneously -
> something only a fuzzer like syzkaller would construct.
>
> >
> > >
> > > diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> > > index 27fe8236f662..248a6995cc53 100644
> > > --- a/drivers/tty/tty_ldisc.c
> > > +++ b/drivers/tty/tty_ldisc.c
> > > @@ -556,15 +556,28 @@ int tty_set_ldisc(struct tty_struct *tty, int disc)
> > > /* Shutdown the old discipline. */
> > > tty_ldisc_close(tty, old_ldisc);
> > >
> > > - /* Now set up the new line discipline. */
> > > - tty->ldisc = new_ldisc;
> > > + /* Clear tty->ldisc so concurrent readers back off during transition */
> > > + tty->ldisc = NULL;
> > > tty_set_termios_ldisc(tty, disc);
> > > + tty_ldisc_unlock(tty);
> > >
> > > + /*
> > > + * Open the new discipline outside ldisc_sem. The ldisc .open()
> > > + * may acquire locks (e.g., rtnl_mutex) that would create circular
> > > + * dependencies if taken under ldisc_sem. tty_lock is still held,
> > > + * preventing concurrent ldisc changes and hangup.
> > > + */
> > > retval = tty_ldisc_open(tty, new_ldisc);
> >
> > Now you are calling open when previously we were not, are you sure this
> > isn't going to cause problems?
> >
>
> This is not a new .open() call - it is the same tty_ldisc_open() that
> was always called here. The change only moves it outside ldisc_sem.
> tty_lock is still held throughout, so .open() sees the same environment
> as before.
Ah, you are right, my bad read of the patch, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
From: Greg KH @ 2026-07-17 10:53 UTC (permalink / raw)
To: Yun Zhou
Cc: jirislaby, socketcan, linux-serial, mkl, linux-can, davem,
edumazet, kuba, pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260716064719.1401892-1-yun.zhou@windriver.com>
On Thu, Jul 16, 2026 at 02:47:19PM +0800, Yun Zhou wrote:
> syzbot reported a circular lock dependency involving tty ldisc_sem and
> the networking rtnl_mutex. The full chain is:
>
> rtnl_mutex --> nft_commit_mutex --> ... --> ep->mtx --> ldisc_sem --> rtnl_mutex
>
> The last edge (ldisc_sem -> rtnl_mutex) is created because tty line
> discipline .open() callbacks (slcan, slip) call register_netdev() which
> acquires rtnl_mutex, and .open() runs under ldisc_sem write lock in
> tty_set_ldisc().
>
> Fix by moving the .open() call outside the ldisc_sem write lock. The
> ldisc .open() is initialization of the NEW discipline after the old one
> has been closed - there is no need for ldisc_sem protection at this
> point since:
>
> - tty_lock is held throughout, preventing concurrent tty_set_ldisc,
> hangup, or close
> - tty->ldisc is set to NULL during the window, so concurrent readers
> (tty_ldisc_ref, tty_ldisc_ref_wait) see NULL and return immediately,
> which callers already handle as a hangup condition
> - tty buffer data stays queued until the ldisc is installed
Ah, but look at the review at:
https://sashiko.dev/#/patchset/20260716064719.1401892-1-yun.zhou@windriver.com
which says:
Does unlocking the semaphore while the ldisc pointer is NULL introduce a UAPI
break for concurrent operations?
If a concurrent process calls read(), write(), or poll() during this unlocked
window, it can enter tty_ldisc_ref_wait() in drivers/tty/tty_io.c. Because the
semaphore was unlocked here, tty_ldisc_ref_wait() will successfully acquire
the read lock but observe tty->ldisc as NULL.
This causes the reader to immediately return EOF or -EIO, potentially
aborting userspace applications unexpectedly during a line discipline
transition.
Is that not true?
thanks,
greg k-h
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Wu. JackBB (GSM) @ 2026-07-17 10:53 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <47002e869f5b4f0985316669d2769c19@compal.com>
Hi Simon,
After further internal review, we agree this needs to be fixed.
On Jack Wu wrote:
>> [Severity: High]
>> Does this code apply a double byte-swap on big-endian architectures?
>T9XX currently only targets x86 (little-endian) platforms where
>cpu_to_le32() is a no-op. The Kconfig enforces "depends on PCI &&
In v5 we will remove LE32_TO_U32(cpu_to_le32(...)) and return
hw_bits directly in both mtk_pci_ext_d2h_evt_hw_bits() and
mtk_pci_ext_h2d_evt_hw_bits(). The custom LE32_TO_U32 macro
will also be removed.
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dt-bindings: net: add DAPU Telecom DAP8211R(I) PHY binding
From: Artem Shimko @ 2026-07-17 10:54 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Paolo Abeni, Maxime Chevallier, linux-kernel, Heiner Kallweit,
netdev, David S . Miller, devicetree, Conor Dooley, Russell King,
Jakub Kicinski, Krzysztof Kozlowski, Andrew Lunn, Eric Dumazet
In-Reply-To: <178422864835.973481.10210790720231842764.robh@kernel.org>
Hi Rob,
On Thu, Jul 16, 2026 at 10:04 PM Rob Herring (Arm) <robh@kernel.org> wrote:
> My bot found errors running 'make dt_binding_check' on your patch:
Oh, thank you, I will try to fix it.
--
Best regards,
Artem
^ permalink raw reply
* Re: [PATCH net v2] net:ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986
From: Simon Horman @ 2026-07-17 10:55 UTC (permalink / raw)
To: hujy652
Cc: Simon Horman, nbd, lorenzo, andrew+netdev, davem, edumazet, kuba,
pabeni, matthias.bgg, angelogioacchino.delregno, sujuan.chen,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260711112128.971-1-hujy652@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
https://sashiko.dev/#/patchset/20260711112128.971-1-hujy652@gmail.com?part=1
---
--- Patch [1]: [PATCH net v2] net:ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986 ---
commit d478e0562d6cafb9be212cb1356ac8344230386e
Author: Zhi-Jun You <hujy652@gmail.com>
net:ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986
WDMA_RING_TX(0) is required to set MTK_WED_WDMA_RING_TX for WED RX but on a
non-DBDC MT7986 it is never setup because idx is 1. Fix this by calling
mtk_wed_wdma_tx_ring_setup if wed is v2 and rx_ring[0] is not allocated.
Link: https://lore.kernel.org/netdev/20260630144831.1109-1-hujy652@gmail.com/
> diff --git a/drivers/net/ethernet/mediatek/mtk_wed.c b/drivers/net/ethernet/mediatek/mtk_wed.c
> --- a/drivers/net/ethernet/mediatek/mtk_wed.c
> +++ b/drivers/net/ethernet/mediatek/mtk_wed.c
> @@ -2334,6 +2334,13 @@ mtk_wed_start(struct mtk_wed_device *dev, u32 irq_mask)
> if (!dev->rx_wdma[i].desc)
> mtk_wed_wdma_rx_ring_setup(dev, i, 16, false);
>
> + /*
> + * non-DBDC MT7986 allocates only rx_ring[1] and tx_wdma[1] during setup
> + * but tx_wdma[0] is also needed for WED to function.
> + */
> + if (mtk_wed_is_v2(dev->hw) && !dev->rx_ring[0].desc)
> + mtk_wed_wdma_tx_ring_setup(dev, 0, MTK_WED_WDMA_RING_SIZE, !!dev->tx_wdma[0].desc);
[Severity: High]
Is it safe to ignore the return value of mtk_wed_wdma_tx_ring_setup() here?
If mtk_wed_ring_alloc() fails under memory pressure, it returns -ENOMEM:
mtk_wed_wdma_tx_ring_setup() {
...
if (!reset && mtk_wed_ring_alloc(dev, wdma, MTK_WED_WDMA_RING_SIZE,
dev->hw->soc->wdma_desc_size, true))
return -ENOMEM;
...
}
Could this result in the hardware being enabled with uninitialized or
zeroed base addresses, potentially leading to DMA faults or system crashes?
Since mtk_wed_start() has the ability to return early on allocation
failure (as seen with mtk_wed_rx_buffer_alloc()), should it abort the
start sequence when this ring setup fails?
[Severity: High]
This isn't a bug introduced by this patch, but when this setup function
is called with reset evaluating to true on v3 hardware, does
mtk_wed_ring_reset() corrupt the v3-specific descriptor initialization?
In mtk_wed_wdma_tx_ring_setup(), v3 hardware initializes desc->info:
mtk_wed_wdma_tx_ring_setup() {
...
if (mtk_wed_is_v3_or_greater(dev->hw)) {
for (i = 0; i < MTK_WED_WDMA_RING_SIZE; i++) {
...
desc->info = cpu_to_le32(MTK_WDMA_TXD0_DESC_INFO_DMA_DONE);
...
}
}
...
if (reset)
mtk_wed_ring_reset(wdma, MTK_WED_WDMA_RING_SIZE, true);
...
}
However, mtk_wed_ring_reset() loops over the ring and unconditionally
clears desc->info:
mtk_wed_ring_reset() {
...
desc->info = 0;
...
}
Could this wipe out the configured v3-specific state and lead to a DMA
stall or faults on v3 hardware?
> +
> if (dev->wlan.hw_rro) {
> for (i = 0; i < MTK_WED_RX_PAGE_QUEUES; i++) {
> u32 addr = MTK_WED_RRO_MSDU_PG_CTRL0(i) +
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 3/7] net: wwan: t9xx: Add control DMA interface
From: Wu. JackBB (GSM) @ 2026-07-17 10:57 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <cacde4a05d6a48afbac6425425fe180c@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On [date] Jack Wu wrote:
>> [Severity: High]
>> Is a dma_rmb() needed after checking the hardware ownership flag?
> The GPD descriptors are allocated from a coherent DMA pool
> (dma_pool_zalloc), so CPU cache coherency is guaranteed by the DMA
> mapping. A dma_rmb() is not needed because coherent memory ensures
> the CPU always observes the latest values written by the device.
We Will remove the rmb() and add dma_rmb() after the HWO check in
both TX and RX done paths:
/* TX done */
if (!req->data_vm_addr ||
(req->gpd->tx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO))
break;
dma_rmb();
/* RX done */
if (req->gpd->rx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO)
break;
dma_rmb();
mtk_cldma_rx_skb_adjust(mdev, rxq, req);
>> [Severity: High]
>> If mtk_cldma_reload_rx_skb fails due to memory pressure, it jumps
>> to out without advancing rxq->free_idx.
> If mtk_cldma_reload_rx_skb() fails, the code jumps to "out" which
> unmasks the interrupt. On the next hardware interrupt, rx_done_work
> runs again and retries from the same free_idx.
Will change the failure path to recycle the old buffer and return
the descriptor to hardware, dropping the current packet to
guarantee forward progress.
>> [Severity: High]
>> Does this code safely handle non-linear SKBs?
> When nr_bds == 0, the SKB is always linear — it is allocated
> internally via __dev_alloc_skb() with data copied via skb_put().
Will change skb->len to skb_headlen(skb).
>> [Severity: High]
>> Could there be a race condition here with mtk_cldma_tx_done_work?
> No race exists. tx_done_work sees HWO still set.
Will add a free_idx == wr_idx boundary check at the top of the
done_work loop (using READ_ONCE/WRITE_ONCE) to prevent done_work
from crossing into submit territory on descriptor reuse.
Thanks
^ permalink raw reply
* [PATCH v2] mac802154: hold an interface reference across the scan worker
From: Ibrahim Hashimov @ 2026-07-17 10:58 UTC (permalink / raw)
To: alex.aring, miquel.raynal, stefan
Cc: linux-wpan, netdev, linux-kernel, stable
In-Reply-To: <20260710140927.13228-1-security@auditcode.ai>
mac802154_scan_worker() captures the scanning sub-interface once under
RCU:
sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(scan_req->wpan_dev);
and then, after rcu_read_unlock() and outside the rtnl, keeps
dereferencing sdata->dev: in the channel-change and restart failure
traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev) for
active scans, in the final dev_dbg(), and in the end_scan
mac802154_scan_cleanup_locked() path. Nothing keeps that netdev alive
for the duration of the worker iteration.
A concurrent teardown of the scanning interface -- userspace issuing
NL802154_CMD_DEL_INTERFACE (ieee802154_if_remove() ->
unregister_netdevice()), or a full PHY removal via
ieee802154_unregister_hw() -> ieee802154_remove_interfaces() -- can run
as soon as the worker drops the rtnl between its two short
drv_set_channel()/drv_start() sections. The netdev is not freed
synchronously by unregister_netdevice(): it is queued to net_todo_list
and freed later from netdev_run_todo(), which drops the rtnl mutex
(__rtnl_unlock()) *before* netdev_wait_allrefs_any()/free_netdev(). The
freeing therefore runs with the rtnl not held, on whichever task next
drains net_todo_list. Holding the rtnl in the worker does not prevent
it, and the per-PHY IEEE802154_IS_SCANNING flag does not identify the
specific interface: a subsequent NEW_INTERFACE + TRIGGER_SCAN re-arms
the flag, so a stale worker iteration sails past an is-scanning recheck
and dereferences the already-freed netdev.
Triggering the race requires CAP_NET_ADMIN: both
NL802154_CMD_TRIGGER_SCAN and NL802154_CMD_DEL_INTERFACE are
GENL_ADMIN_PERM, reachable only from the initial user namespace, so
the attacker is a locally privileged (CAP_NET_ADMIN) user, not an
unprivileged local user or a remote peer.
KASAN slab-use-after-free, kworker reading the freed
net_device/ieee802154_sub_if_data (kmalloc-cg-4k) allocated and freed by
the racing NEW_INTERFACE/DEL_INTERFACE task:
BUG: KASAN: slab-use-after-free in mac802154_scan_worker+0x... [mac802154]
Read of size 8 ... by task kworker/u8:N
Workqueue: phy0-mac-cmds mac802154_scan_worker [mac802154]
mac802154_scan_worker
process_one_work
Fix it by taking a reference on the interface while the RCU read lock is
still held -- so the netdev cannot be freed before the refcount is
raised -- and releasing it at every exit of the worker past that point.
This keeps sdata->dev valid for the whole iteration. The reference does
not defer the free indefinitely: a teardown started while it is held
simply blocks in netdev_run_todo() until the current iteration returns,
and it cannot self-deadlock the single-threaded mac_wq because the
unregistering task claims the net_todo_list entry under the rtnl, so the
blocking netdev_wait_allrefs_any() always runs on that task, not on the
worker.
Verified on a v6.19 KASAN build: racing DEL_INTERFACE against an
in-flight TRIGGER_SCAN reliably tripped a slab-use-after-free KASAN
report inside mac802154_scan_worker() before this patch, and the
same reproducer no longer triggers it with the fix applied.
Fixes: 57588c71177f ("mac802154: Handle passive scanning")
Cc: stable@vger.kernel.org
Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
Assisted-by: AuditCode-AI:2026.07
---
v2: trim the in-worker comment down to the essentials, as requested by
Miquel Raynal. No functional change.
net/mac802154/scan.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 300d4584533e..5b4ea2a895cc 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -209,6 +209,14 @@ void mac802154_scan_worker(struct work_struct *work)
return;
}
+ /*
+ * sdata->dev is dereferenced below after rcu_read_unlock() and outside
+ * the rtnl, and a concurrent DEL_INTERFACE / PHY teardown can free it
+ * asynchronously from netdev_run_todo(). Pin it with a reference taken
+ * while the RCU read lock is still held, and drop it at every exit.
+ */
+ dev_hold(sdata->dev);
+
wpan_phy = scan_req->wpan_phy;
scan_req_type = scan_req->type;
scan_req_duration = scan_req->duration;
@@ -262,12 +270,14 @@ void mac802154_scan_worker(struct work_struct *work)
"Scan page %u channel %u for %ums\n",
page, channel, jiffies_to_msecs(scan_duration));
queue_delayed_work(local->mac_wq, &local->scan_work, scan_duration);
+ dev_put(sdata->dev);
return;
end_scan:
rtnl_lock();
mac802154_scan_cleanup_locked(local, sdata, false);
rtnl_unlock();
+ dev_put(sdata->dev);
}
int mac802154_trigger_scan_locked(struct ieee802154_sub_if_data *sdata,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* RE: [External Mail] Re: [PATCH v4 4/7] net: wwan: t9xx: Add control port
From: Wu. JackBB (GSM) @ 2026-07-17 11:00 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <3a3b077758604433a0ddca3f3467a561@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On [date] Jack Wu wrote:
>> [Severity: High]
>> Can this lead to use-after-free and double-free on the skb?
> No. The recv callback (mtk_port_internal_recv) does not free
> the skb on error — it returns -ENXIO and leaves skb ownership
> with the caller.
>> [Severity: High]
>> This is where the second free of the skb occurs when propagating
>> the error from the recv callback.
> As above, the recv callback does not free the skb on error.
>> [Severity: High]
>> This is where the skb is freed on the error path before returning
>> -ENXIO.
> mtk_port_internal_recv() does not call dev_kfree_skb_any() on the
> error path.
Our previous response was incorrect. In Patch 4's code,
mtk_port_internal_recv's drop_data does have
dev_kfree_skb_any(skb) — the double-free and UAF are real.
Will remove dev_kfree_skb_any(skb) from
mtk_port_internal_recv's drop_data path in v5. The caller
(mtk_port_rx_dispatch) is the sole owner and frees the skb
on error.
>> [Severity: High]
>> Could this create an infinite loop in kernel space?
> This is intentional. Channel enable/disable are control plane
> operations that must complete or timeout. The loop does not
> busy-spin: each iteration sleeps in
> wait_event_interruptible_timeout until the condition is met or
> the timeout expires.
>> [Severity: High]
>> This appears to have the same infinite loop risk.
> Same reasoning as mtk_port_ch_enable.
Will change wait_event_interruptible_timeout to
wait_event_timeout in both mtk_port_ch_enable and
mtk_port_ch_disable, and remove the -ERESTARTSYS / goto
start_wait block.
>> [Severity: High]
>> Missing bounds check on msg->port_cnt in
>> mtk_port_status_update.
> The message is already validated by head_pattern, tail_pattern,
> and version checks before the loop. The modem firmware is a
> trusted source.
Will move data_len validation before the callback call in
mtk_fsm_parse_hs2_msg, pass data_len to the callback, and add
a bounds check in mtk_port_status_update:
if (data_len < sizeof(*msg) +
le16_to_cpu(msg->port_cnt) * sizeof(*port_info))
return -EPROTO;
Thanks.
Jack Wu
^ permalink raw reply
* [PATCH net-next,v3] xfrm: allow to enable udp encapsulation without userspace socket
From: Pablo Neira Ayuso @ 2026-07-17 11:01 UTC (permalink / raw)
To: devel; +Cc: netdev, tobias, eyal.birger, antony, steffen.klassert
It is currently not possible to enable UDP encapsulation in xfrm without
a userspace process that listens on the specified UDP listener port in
the SA.
People have work around this by creating dummy userspace daemons such as
the one in the smallish perl program (see the script at the bottom of
this link):
http://techblog.newsnow.co.uk/2011/11/simple-udp-esp-encapsulation-nat-t-for.html
This patch adds XFRM_SA_XFLAG_UDP_ENCAP_SOCK to create the UDP socket
from the kernel.
Use a hole in net->xfrm to place the new encap_socket list.
The following example shows how to enable the standalone UDP
encapsulation:
ip xfrm state add src 192.168.10.10 dst 192.168.10.11 proto esp spi 1 \
encap espinudp 9999 9999 0.0.0.0 \
if_id 0x1 reqid 1 replay-window 0 mode tunnel aead 'rfc4106(gcm(aes))' \
0x1111111111111111111111111111111111111111 96 \
sel src 10.141.10.0/24 dst 10.141.11.0/24 dir out
and the receiving side uses 'extra-flag udp-encap-sock':
ip xfrm state add src 192.168.10.11 dst 192.168.10.10 proto esp spi 2 \
encap espinudp 9999 0 0.0.0.0 extra-flag udp-encap-sock \
if_id 0x1 reqid 2 replay-window 10 mode tunnel aead 'rfc4106(gcm(aes))' \
0x2222222222222222222222222222222222222222 96 dir in
This allows for multiple SAs using the same listener udp port.
This is useful for testing scenarios where UDP encapsulation is
required.
Note this patch exports xfrm6_udp_encap_rcv() just like
xfrm4_udp_encap_rcv() otherwise linker complains due to unreachable
symbol.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
v3: - Use x->id.daddr.a{4,6} instead of encap_oa, as suggested by Eyal and Tobias.
- Fix several SA using same udp encapsulation configuration.
This is a follow up to:
https://lists.linux-ipsec.org/archives/list/devel@lists.linux-ipsec.org/thread/F4IOY2DKFDX3E45UUFQHUZKTHV7AD6G4/
NOTE for netdev maintainers:
Targetting net-next so sashiko kicks in for review, ipsec-devel still has no such service yet.
include/net/netns/xfrm.h | 1 +
include/net/xfrm.h | 11 ++++
include/uapi/linux/xfrm.h | 1 +
net/ipv6/xfrm6_input.c | 1 +
net/xfrm/Kconfig | 2 +
net/xfrm/xfrm_state.c | 16 +++++
net/xfrm/xfrm_user.c | 122 +++++++++++++++++++++++++++++++++++++-
7 files changed, 152 insertions(+), 2 deletions(-)
diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
index b73983a17e08..5091c07b1e46 100644
--- a/include/net/netns/xfrm.h
+++ b/include/net/netns/xfrm.h
@@ -56,6 +56,7 @@ struct netns_xfrm {
unsigned int policy_count[XFRM_POLICY_MAX * 2];
struct work_struct policy_hash_work;
struct xfrm_policy_hthresh policy_hthresh;
+ struct hlist_head encap_socket;
struct list_head inexact_bins;
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index a6d69aaa6cd2..99730a2fc8b9 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -25,6 +25,7 @@
#include <net/ipv6.h>
#include <net/ip6_fib.h>
#include <net/flow.h>
+#include <net/udp_tunnel.h>
#include <net/gro_cells.h>
#include <linux/interrupt.h>
@@ -169,6 +170,13 @@ struct xfrm_dev_offload {
u8 flags : 2;
};
+struct xfrm_encap_sock {
+ struct hlist_node list;
+ struct udp_port_cfg cfg;
+ struct sock *sk;
+ refcount_t refcnt;
+};
+
struct xfrm_mode {
u8 encap;
u8 family;
@@ -249,6 +257,7 @@ struct xfrm_state {
/* Data for encapsulator */
struct xfrm_encap_tmpl *encap;
+ struct xfrm_encap_sock *encap_sock;
/* NAT keepalive */
u32 nat_keepalive_interval; /* seconds */
@@ -2343,6 +2352,8 @@ static inline bool xfrm6_local_dontfrag(const struct sock *sk)
}
#endif
+int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb);
+
#if (IS_BUILTIN(CONFIG_XFRM_INTERFACE) && IS_ENABLED(CONFIG_DEBUG_INFO_BTF)) || \
(IS_MODULE(CONFIG_XFRM_INTERFACE) && IS_ENABLED(CONFIG_DEBUG_INFO_BTF_MODULES))
diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
index 051f8066efd1..28aa5c8ca317 100644
--- a/include/uapi/linux/xfrm.h
+++ b/include/uapi/linux/xfrm.h
@@ -413,6 +413,7 @@ struct xfrm_usersa_info {
#define XFRM_SA_XFLAG_DONT_ENCAP_DSCP 1
#define XFRM_SA_XFLAG_OSEQ_MAY_WRAP 2
+#define XFRM_SA_XFLAG_UDP_ENCAP_SOCK 4
struct xfrm_usersa_id {
xfrm_address_t daddr;
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index 89d0443b5307..2e3f7b9e5a4f 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -173,6 +173,7 @@ int xfrm6_udp_encap_rcv(struct sock *sk, struct sk_buff *skb)
return ret;
}
+EXPORT_SYMBOL(xfrm6_udp_encap_rcv);
struct sk_buff *xfrm6_gro_udp_encap_rcv(struct sock *sk, struct list_head *head,
struct sk_buff *skb)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 4a62817a88f8..fe42cfca9423 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -7,6 +7,7 @@ config XFRM
depends on INET
select GRO_CELLS
select SKB_EXTENSIONS
+ select NET_UDP_TUNNEL
config XFRM_OFFLOAD
bool
@@ -23,6 +24,7 @@ if INET
config XFRM_USER
tristate "Transformation user configuration interface"
select XFRM_ALGO
+ select NET_UDP_TUNNEL
help
Support for Transformation(XFRM) user configuration interface
like IPsec used by native Linux tools.
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 36a4f6793ede..c849e7ac750a 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -27,6 +27,7 @@
#include <linux/slab.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <net/udp_tunnel.h>
#include <crypto/aead.h>
@@ -586,6 +587,16 @@ static const struct xfrm_mode_cbs *xfrm_get_mode_cbs(u8 mode)
return cbs;
}
+static bool xfrm_socket_put(struct xfrm_encap_sock *encap_sock)
+{
+ if (refcount_dec_and_test(&encap_sock->refcnt)) {
+ udp_tunnel_sock_release(encap_sock->sk);
+ return true;
+ }
+
+ return false;
+}
+
void xfrm_state_free(struct xfrm_state *x)
{
kmem_cache_free(xfrm_state_cache, x);
@@ -597,6 +608,10 @@ static void xfrm_state_gc_destroy(struct xfrm_state *x)
{
if (x->mode_cbs && x->mode_cbs->destroy_state)
x->mode_cbs->destroy_state(x);
+
+ if (x->encap_sock && xfrm_socket_put(x->encap_sock))
+ kfree(x->encap_sock);
+
hrtimer_cancel(&x->mtimer);
timer_delete_sync(&x->rtimer);
kfree_sensitive(x->aead);
@@ -3332,6 +3347,7 @@ int __net_init xfrm_state_init(struct net *net)
SLAB_HWCACHE_ALIGN | SLAB_PANIC);
INIT_LIST_HEAD(&net->xfrm.state_all);
+ INIT_HLIST_HEAD(&net->xfrm.encap_socket);
sz = sizeof(struct hlist_head) * 8;
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index d6db63304ba6..bc88581e51e8 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -29,6 +29,7 @@
#include <net/xfrm.h>
#include <net/netlink.h>
#include <net/ah.h>
+#include <net/udp_tunnel.h>
#include <linux/uaccess.h>
#if IS_ENABLED(CONFIG_IPV6)
#include <linux/in6.h>
@@ -484,6 +485,17 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
goto out;
}
+ if (attrs[XFRMA_SA_EXTRA_FLAGS]) {
+ u32 xflags = nla_get_u32(attrs[XFRMA_SA_EXTRA_FLAGS]);
+
+ if (xflags & XFRM_SA_XFLAG_UDP_ENCAP_SOCK &&
+ (!sa_dir || sa_dir == XFRM_SA_DIR_OUT)) {
+ NL_SET_ERR_MSG(extack, "Flag UDP_ENCAP_SOCK can only be set on input SA");
+ err = -EINVAL;
+ goto out;
+ }
+ }
+
if (sa_dir == XFRM_SA_DIR_OUT) {
if (p->flags & XFRM_STATE_DECAP_DSCP) {
NL_SET_ERR_MSG(extack, "Flag DECAP_DSCP should not be set for output SA");
@@ -556,7 +568,6 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
err = -EINVAL;
goto out;
}
-
}
if (attrs[XFRMA_IPTFS_DONT_FRAG]) {
@@ -932,9 +943,17 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
goto error;
}
- if (attrs[XFRMA_SA_EXTRA_FLAGS])
+ if (attrs[XFRMA_SA_EXTRA_FLAGS]) {
x->props.extra_flags = nla_get_u32(attrs[XFRMA_SA_EXTRA_FLAGS]);
+ if (x->props.extra_flags & XFRM_SA_XFLAG_UDP_ENCAP_SOCK &&
+ x->encap && x->encap->encap_type != UDP_ENCAP_ESPINUDP) {
+ NL_SET_ERR_MSG(extack, "XFRM_SA_XFLAG_UDP_ENCAP_SOCK can only be set on UDP_ENCAP_ESPINUDP type");
+ err = -EOPNOTSUPP;
+ goto error;
+ }
+ }
+
if ((err = attach_aead(x, attrs[XFRMA_ALG_AEAD], extack)))
goto error;
if ((err = attach_auth_trunc(&x->aalg, &x->props.aalgo,
@@ -1036,6 +1055,97 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
return NULL;
}
+static struct xfrm_encap_sock *
+xfrm_socket_find_get(struct net *net, const struct udp_port_cfg *udp_conf)
+{
+ struct xfrm_encap_sock *listener;
+
+ hlist_for_each_entry(listener, &net->xfrm.encap_socket, list) {
+ if (!memcmp(&listener->cfg, udp_conf, sizeof(*udp_conf))) {
+ refcount_inc(&listener->refcnt);
+ return listener;
+ }
+ }
+
+ return NULL;
+}
+
+static int xfrm_socket_encap_create(struct net *net, struct xfrm_state *x,
+ struct udp_port_cfg *udp_conf,
+ struct udp_tunnel_sock_cfg *tuncfg)
+{
+ struct xfrm_encap_sock *listener;
+ struct socket *sock;
+ int err;
+
+ listener = kzalloc_obj(*listener);
+ if (!listener)
+ return -ENOMEM;
+
+ err = udp_sock_create(net, udp_conf, &sock);
+ if (err) {
+ kfree(listener);
+ return err;
+ }
+ setup_udp_tunnel_sock(net, sock->sk, tuncfg);
+
+ listener->sk = sock->sk;
+ listener->cfg = *udp_conf;
+ refcount_set(&listener->refcnt, 1);
+ hlist_add_head(&listener->list, &net->xfrm.encap_socket);
+
+ x->encap_sock = listener;
+
+ return 0;
+}
+
+static int xfrm_socket_setup(struct net *net, struct xfrm_state *x,
+ struct netlink_ext_ack *extack)
+{
+ struct udp_tunnel_sock_cfg tuncfg = {};
+ struct xfrm_encap_sock *listener;
+ struct udp_port_cfg udp_conf;
+ int err;
+
+ if (!x->encap)
+ return -EOPNOTSUPP;
+
+ memset(&udp_conf, 0, sizeof(udp_conf));
+ udp_conf.family = x->props.family;
+
+ switch (x->props.family) {
+ case AF_INET:
+ udp_conf.local_ip.s_addr = x->id.daddr.a4;
+ tuncfg.encap_rcv = xfrm4_udp_encap_rcv;
+ break;
+#if IS_ENABLED(CONFIG_IPV6)
+ case AF_INET6:
+ udp_conf.local_ip6 = x->id.daddr.in6;
+ tuncfg.encap_rcv = xfrm6_udp_encap_rcv;
+ break;
+#endif
+ default:
+ return -EOPNOTSUPP;
+ }
+ udp_conf.local_udp_port = x->encap->encap_sport;
+
+ listener = xfrm_socket_find_get(net, &udp_conf);
+ if (listener) {
+ x->encap_sock = listener;
+ return 0;
+ }
+
+ tuncfg.encap_type = UDP_ENCAP_ESPINUDP;
+
+ err = xfrm_socket_encap_create(net, x, &udp_conf, &tuncfg);
+ if (err < 0) {
+ NL_SET_ERR_MSG(extack, "Cannot initialize kernel UDP socket");
+ return err;
+ }
+
+ return 0;
+}
+
static int xfrm_add_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
struct nlattr **attrs, struct netlink_ext_ack *extack)
{
@@ -1053,6 +1163,14 @@ static int xfrm_add_sa(struct sk_buff *skb, struct nlmsghdr *nlh,
if (!x)
return err;
+ if (x->props.extra_flags & XFRM_SA_XFLAG_UDP_ENCAP_SOCK) {
+ err = xfrm_socket_setup(net, x, extack);
+ if (err < 0) {
+ x->km.state = XFRM_STATE_DEAD;
+ goto out;
+ }
+ }
+
xfrm_state_hold(x);
if (nlh->nlmsg_type == XFRM_MSG_NEWSA)
err = xfrm_state_add(x);
--
2.47.3
^ permalink raw reply related
* RE: [External Mail] Re: [PATCH v4 5/7] net: wwan: t9xx: Add FSM thread
From: Wu. JackBB (GSM) @ 2026-07-17 11:02 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <cbd2ef0bba8e46efb19f692a2e114149@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On Jack Wu wrote:
>> [Severity: High]
>> Infinite busy loop on signal pending.
> This is intentional. Channel disable must complete or timeout.
> The loop does not busy-spin: each iteration sleeps in
> wait_event_interruptible_timeout until the condition is met or
> the timeout expires.
Will change wait_event_interruptible_timeout to
wait_event_timeout and remove the -ERESTARTSYS / goto
start_wait block.
>> [Severity: High]
>> Race in mtk_fsm_evt_submit — fsm_handler NULL after spinlock
>> release.
> The GATECLOSED check under evtq_lock ensures fsm_handler is
> valid. After the check passes, the event is submitted and the
> kthread is woken.
Will move wake_up_process inside evtq_lock in evt_submit, and
have mtk_fsm_exit clear fsm_handler under evtq_lock:
evt_submit:
wake_up_process(fsm->fsm_handler);
spin_unlock_irqrestore(&fsm->evtq_lock, flags);
mtk_fsm_exit:
spin_lock_irqsave(&fsm->evtq_lock, flags);
handler = fsm->fsm_handler;
fsm->fsm_handler = NULL;
spin_unlock_irqrestore(&fsm->evtq_lock, flags);
if (handler)
kthread_stop(handler);
>> [Severity: High]
>> rtft_entry->data passed to action callback before data_len
>> validation.
> The action functions only read fixed-size fields. The modem
> firmware is a trusted source.
Will move data_len validation before the callback call in
mtk_fsm_parse_hs2_msg, and pass data_len to the callback.
>> [Severity: High]
>> Uninitialized kernel heap memory in mtk_fsm_send_hs3_msg.
> The reserved[2] field is sent to the local modem over PCIe DMA,
> not exposed to external networks.
Will add memset(skb->data, 0, RTFT_DATA_SIZE) after
__dev_alloc_skb in mtk_fsm_send_hs3_msg.
>> [Severity: High]
>> Silent kcalloc failure in mtk_port_disable.
> Allocation failure is extremely unlikely. Hardware has already
> been power-cycled via PLDR.
Will replace radix_tree_gang_lookup with radix_tree_for_each_slot,
eliminating the temporary array. Same pattern as
mtk_port_search_by_name.
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH net v2 1/2] net: pse-pd: stop async event sources before freeing PI data in unregister
From: Simon Horman @ 2026-07-17 11:07 UTC (permalink / raw)
To: github
Cc: Simon Horman, o.rempel, kory.maincent, andrew+netdev, davem,
edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260711121611.1639086-2-github@szelinsky.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
https://sashiko.dev/#/patchset/20260711121611.1639086-2-github@szelinsky.de?part=1
---
--- Patch [1]: [PATCH net v2 1/2] net: pse-pd: stop async event sources before freeing PI data in unregister ---
commit bc4c653b9b2b42b2c22ca8b6cae3af394c8add0e
Author: Carlo Szelinsky <github@szelinsky.de>
net: pse-pd: stop async event sources before freeing PI data in unregister
This commit reorders the teardown process in pse_controller_unregister().
It disables the IRQ and flushes the notification worker before flushing power
domains and releasing the PI array. This is intended to prevent use-after-free
issues caused by asynchronous accessors referencing freed data structures.
> diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
> index a5e6d7b26b9fd..6045b6c399c26 100644
> --- a/drivers/net/pse-pd/pse_core.c
> +++ b/drivers/net/pse-pd/pse_core.c
> @@ -1114,11 +1114,15 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
> */
> void pse_controller_unregister(struct pse_controller_dev *pcdev)
> {
> - pse_flush_pw_ds(pcdev);
> - pse_release_pis(pcdev);
> + /* Stop the IRQ and notification worker before freeing what they
> + * reach: both touch pcdev->pi, and the IRQ also uses pw_d->supply
> + * that pse_flush_pw_ds() drops.
> + */
> if (pcdev->irq)
> disable_irq(pcdev->irq);
[Severity: High]
Does this code call disable_irq() on an already freed IRQ line?
In tps23881.c, devm_pse_controller_register() is called before
tps23881_setup_irq(). Because devres executes teardown actions in LIFO order,
the IRQ is freed before pse_controller_unregister() runs.
Calling disable_irq() here operates on a freed IRQ descriptor, which can cause
warnings or corrupt state.
> cancel_work_sync(&pcdev->ntf_work);
> + pse_flush_pw_ds(pcdev);
> + pse_release_pis(pcdev);
[Severity: High]
This isn't a bug introduced by this patch, but releasing the PIs here causes a
use-after-free via sysfs.
In pse_controller_register(), PI regulators are registered via
devm_pse_pi_regulator_register() before devm_pse_controller_register() is called
by the driver. Devres LIFO ordering means pse_controller_unregister() runs
first, freeing pcdev->pi.
The regulators remain active until their devres actions run later.
If a user space read via sysfs triggers pse_pi_is_enabled() during this window,
it will dereference the freed pcdev->pi array.
[Severity: High]
This is a pre-existing issue, but does freeing the power domains here create a
use-after-free for shared domains?
In pse_register_pw_ds(), shared power domains are added to a global pse_pw_d_map
and their refcount is incremented, but they are allocated with devm_kzalloc()
tied to a specific device.
When the original allocating device is unbound, devres frees the memory, leaving
dangling pointers in the global map and in any other device sharing the domain.
> kfifo_free(&pcdev->ntf_fifo);
> mutex_lock(&pse_list_mutex);
> list_del(&pcdev->list);
[Severity: High]
This is a pre-existing issue, but does destroying internal data structures
before removing the controller from the global list create a use-after-free?
Because pse_release_pis() runs before list_del(), a concurrent device probe
calling of_pse_control_get() can iterate over pse_controller_list, call
of_pse_match_pi(), and dereference the already-freed pcdev->pi[i].np.
[Severity: High]
This is a pre-existing issue, but the PSE control references don't seem to
manage object lifetime properly.
When a consumer gets a control via of_pse_control_get(), it takes a module
reference but does not establish a device link enforcing that the supplier
outlives the consumer.
If the PSE controller is unbound via sysfs, this teardown path frees pcdev->pi.
The active consumer can then dereference freed memory when it later calls
__pse_control_release().
[Severity: Medium]
This is a pre-existing issue, but does pse_controller_register() leak memory on
error paths?
If setup steps fail after allocating the kfifo and the PI structures (e.g.,
missing callbacks or setup_pi_matrix() failures), the function returns the
error without calling kfifo_free() or pse_release_pis().
^ permalink raw reply
* Re: [PATCH net v2] net: dpaa: fix mode setting
From: Paolo Abeni @ 2026-07-17 11:11 UTC (permalink / raw)
To: Michael Walle, Sean Anderson, Madalin Bucur, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Russell King
Cc: netdev, linux-kernel
In-Reply-To: <DK0RLUBEKFVS.168UHY5BP8D4E@kernel.org>
On 7/17/26 12:13 PM, Michael Walle wrote:
> On Fri Jul 17, 2026 at 12:01 PM CEST, Paolo Abeni wrote:
>> On 7/10/26 4:47 PM, Michael Walle wrote:
>>> On Fri Jul 10, 2026 at 4:39 PM CEST, Sean Anderson wrote:
>>>> On 7/10/26 10:22, Michael Walle wrote:
>>>>> Before converting to the phylink interface, the init function would have
>>>>> set the correct I/F mode depending on the maximum link speed of an
>>>>> interface. After converting to phylink, the established link speed
>>>>> is used to determine this setting and is set in the .link_up()
>>>>> callback. The callback isn't called because the link is never
>>>>> established between the PCS and a connected SGMII PHY.
>>>>> To fix it, don't use the current speed, but set the mode depending on
>>>>> the interface (which implies the maximum speed) in .mac_config().
>>>>>
>>>>> Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink")
>>>>> Suggested-by: Sean Anderson <sean.anderson@linux.dev>
>>>>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>>>>> ---
>>>>> FWIW, I dropped setting a non-reserved mode in init(). The hardware
>>>>> default is 0 and the mac_config() will set a valid mode anyway.
>>>>>
>>>>> Changes in v2:
>>>>> - the setting is/was based on the maximum speed, not the current
>>>>> speed. thus, move the setting into mac_config().
>>>>> - Link to v1: https://lore.kernel.org/r/20260706121011.1948906-1-mwalle@kernel.org/
>>>>>
>>>>> .../net/ethernet/freescale/fman/fman_dtsec.c | 26 ++++++++++---------
>>>>> 1 file changed, 14 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>>>>> index fe35703c509e..7075f93bab49 100644
>>>>> --- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>>>>> +++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>>>>> @@ -900,22 +900,28 @@ static void dtsec_mac_config(struct phylink_config *config, unsigned int mode,
>>>>> {
>>>>> struct mac_device *mac_dev = fman_config_to_mac(config);
>>>>> struct dtsec_regs __iomem *regs = mac_dev->fman_mac->regs;
>>>>> - u32 tmp;
>>>>> + u32 ecntrl, maccfg2;
>>>>> +
>>>>> + maccfg2 = ioread32be(®s->maccfg2);
>>>>> + maccfg2 &= ~(MACCFG2_NIBBLE_MODE | MACCFG2_BYTE_MODE);
>>>>>
>>>>> switch (state->interface) {
>>>>> case PHY_INTERFACE_MODE_RMII:
>>>>> - tmp = DTSEC_ECNTRL_RMM;
>>>>> + ecntrl = DTSEC_ECNTRL_RMM;
>>>>> + maccfg2 |= MACCFG2_NIBBLE_MODE;
>>>>> break;
>>>>> case PHY_INTERFACE_MODE_RGMII:
>>>>> case PHY_INTERFACE_MODE_RGMII_ID:
>>>>> case PHY_INTERFACE_MODE_RGMII_RXID:
>>>>> case PHY_INTERFACE_MODE_RGMII_TXID:
>>>>> - tmp = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
>>>>> + ecntrl = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
>>>>> + maccfg2 |= MACCFG2_BYTE_MODE;
>>>>> break;
>>>>> case PHY_INTERFACE_MODE_SGMII:
>>>>> case PHY_INTERFACE_MODE_1000BASEX:
>>>>> case PHY_INTERFACE_MODE_2500BASEX:
>>>>> - tmp = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
>>>>> + ecntrl = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
>>>>> + maccfg2 |= MACCFG2_BYTE_MODE;
>>>>> break;
>>>>> default:
>>>>> dev_warn(mac_dev->dev, "cannot configure dTSEC for %s\n",
>>>>> @@ -923,7 +929,8 @@ static void dtsec_mac_config(struct phylink_config *config, unsigned int mode,
>>>>> return;
>>>>> }
>>>>>
>>>>> - iowrite32be(tmp, ®s->ecntrl);
>>>>> + iowrite32be(ecntrl, ®s->ecntrl);
>>>>> + iowrite32be(maccfg2, ®s->maccfg2);
>>>>> }
>>>>>
>>>>> static void dtsec_link_up(struct phylink_config *config, struct phy_device *phy,
>>>>> @@ -948,15 +955,10 @@ static void dtsec_link_up(struct phylink_config *config, struct phy_device *phy,
>>>>> iowrite32be(tmp, ®s->ecntrl);
>>>>>
>>>>> tmp = ioread32be(®s->maccfg2);
>>>>> - tmp &= ~(MACCFG2_NIBBLE_MODE | MACCFG2_BYTE_MODE | MACCFG2_FULL_DUPLEX);
>>>>> - if (speed >= SPEED_1000)
>>>>> - tmp |= MACCFG2_BYTE_MODE;
>>>>> - else
>>>>> - tmp |= MACCFG2_NIBBLE_MODE;
>>>>> -
>>>>> if (duplex == DUPLEX_FULL)
>>>>> tmp |= MACCFG2_FULL_DUPLEX;
>>>>> -
>>>>> + else
>>>>> + tmp &= ~MACCFG2_FULL_DUPLEX;
>>>>
>>>> Did you test this when forcing 10/100 speed?
>>>
>>> No I didn't. Well I can't. I have a very weird board which only
>>> supports 1000base-X (and copper SFPs in 1000basex autoneg mode). On
>>> top of that there is a Marvell 88E1112 in between the SFP and the
>>> MAC, for which the PHY driver is completely broken. Long story
>>> short, I'm not able to test that (yet/at all? Not sure).
>> FTR, sashiko suspect this patch will broke such setup:
>> https://sashiko.dev/#/patchset/20260710143430.2276141-1-mwalle%40kernel.org
>
> I've seen that, but.. that was the actual change between v1 and v2
> as suggested by Sean. It does not depend on the actual link speed,
> but the maximum link speed. So it is not relevant if the link
> negotiates to a slower speed or not. At least that now matches the
> behavior prior to the phylink conversion. If that was working -
> that I can't tell you.
I'm sorry, following all cross revision discussion is a bit hard here.
I don't understand if the 'link never established' is specific of your
board, or it a constant with this driver. Could you please clarify?
/P
^ permalink raw reply
* Re: [PATCH v5 4/4] dmaengine: xilinx_dma: Extend metadata handling for AXI DMA and MCDMA
From: Pandey, Radhey Shyam @ 2026-07-17 11:19 UTC (permalink / raw)
To: Srinivas Neeli, Vinod Koul, Radhey Shyam Pandey
Cc: Frank Li, Michal Simek, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Suraj Gupta,
Marek Vasut, Tomi Valkeinen, Alex Bereza, Folker Schwesinger,
dmaengine, netdev, linux-arm-kernel, linux-kernel, git
In-Reply-To: <20260717090824.2364230-5-srinivas.neeli@amd.com>
On 7/17/2026 2:38 PM, Srinivas Neeli wrote:
> From: Suraj Gupta <suraj.gupta2@amd.com>
>
> xilinx_dma_get_metadata_ptr() returns the AXI DMA APP words from the SOP
> descriptor in both directions. This is wrong for RX, where the hardware
> writes the APP words into the EOF descriptor. It also leaves AXI MCDMA
> without metadata support.
>
> Return the metadata from the SOP descriptor for TX and from the EOF
> descriptor for RX, matching where the hardware reads and writes the
> fields. For AXI DMA, expose the APP words (20 bytes). For AXI MCDMA,
> expose the control sideband, status, and APP fields (28 bytes). On TX
> the control sideband holds TID and TUSER configuration for the outgoing
> stream. On RX the sideband status holds the received TID, TDEST and TUSER
> from the incoming stream. The field layout differs between MM2S and S2MM,
> and the wider payload lets a consumer distinguish the two controllers.
> No in-tree consumer is affected.
>
> Read xlnx,axistream-connected for AXI MCDMA. Attach metadata_ops in
> xilinx_mcdma_prep_slave_sg() when an AXI4-Stream interface is present,
> so MCDMA clients use the metadata API the same way as AXI DMA clients.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> Changes in V5:
> - Take the metadata pointer from the SOP descriptor for TX and the EOF
> descriptor for RX, matching where the hardware reads and writes the
> fields (TX previously used the EOF descriptor).
> - AXI DMA now exposes only the APP words (20 bytes) in both directions,
> instead of the status word followed by APP (24 bytes).
> - AXI MCDMA exposes the control sideband, status and APP fields
> (28 bytes), with the sideband position differing between MM2S and S2MM.
> - Reworked the kernel-doc index table and commit message accordingly.
>
> Changes in V4:
> - Restructured xilinx_dma_get_metadata_ptr(): AXIDMA is now the
> fall-through path instead of a separate branch guarded by
> WARN_ON_ONCE()/ERR_PTR().
> - Rewrote the kernel-doc as an index table covering AXI DMA, MCDMA S2MM
> and MCDMA MM2S, and documented that the pointer and payload length are
> the same for both MCDMA directions.
> - Added an inline comment explaining the union aliasing.
> - Condensed the commit message.
>
> Changes in V3:
> - Renamed subject to include "AXI DMA and MCDMA" (was "AXI MCDMA" only).
> - Complete rewrite of commit message and implementation.
> - Metadata pointer now returns status field at index 0 instead of APP
> fields, exposing status and sideband information to clients.
> - Changed from list_first_entry to list_last_entry to return the EOF
> descriptor where hardware writes status and APP fields.
> - Added explicit handling for both AXIDMA and MCDMA types with proper
> payload length calculation.
> - Added WARN_ON_ONCE for unsupported DMA types.
> - Removed the 'chan' field from struct xilinx_dma_tx_descriptor (was
> added in V2) as it's no longer needed; channel is obtained from
> tx->chan instead.
> - Dropped V2 patches 4/5 (dt-bindings xlnx,include-stscntrl-strm) and
> 5/5 (xferred_bytes support) as the approach changed to use residue.
>
> Changes in V2:
> - Added support for MCDMA metadata handling alongside AXIDMA.
> - Added 'chan' field to struct xilinx_dma_tx_descriptor.
> ---
> drivers/dma/xilinx/xilinx_dma.c | 48 +++++++++++++++++++++++++++++----
> 1 file changed, 43 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 1b5b00f08c5f..6bf509d33e7c 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -651,17 +651,51 @@ static inline void xilinx_aximcdma_buf(struct xilinx_dma_chan *chan,
> * @tx: async transaction descriptor
> * @payload_len: metadata payload length
> * @max_len: metadata max length
> - * Return: The app field pointer.
> + *
> + * The metadata lives in the SOP descriptor for TX and the EOF descriptor for RX.
> + * Field order depends on dmatype and direction:
> + *
> + * AXI DMA: [0..] app
> + * AXI MCDMA (TX): [0] ctrl_sideband, [1] status, [2..] app
> + * AXI MCDMA (RX): [0] status, [1] sideband, [2..] app
> + *
> + * Return: Pointer to the first metadata word.
> */
> static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
> size_t *payload_len, size_t *max_len)
> {
> struct xilinx_dma_tx_descriptor *desc = to_dma_tx_descriptor(tx);
> + struct xilinx_dma_chan *chan = to_xilinx_chan(tx->chan);
> +
> + if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> + struct xilinx_aximcdma_tx_segment *seg;
> +
> + if (chan->direction == DMA_DEV_TO_MEM) {
> + seg = list_last_entry(&desc->segments,
> + struct xilinx_aximcdma_tx_segment, node);
> + *max_len = *payload_len = sizeof(seg->hw.s2mm_status) +
> + sizeof(seg->hw.s2mm_sideband_status) +
> + sizeof(seg->hw.app);
> + return &seg->hw.s2mm_status;
> + }
> + seg = list_first_entry(&desc->segments,
> + struct xilinx_aximcdma_tx_segment, node);
> + *max_len = *payload_len = sizeof(seg->hw.mm2s_ctrl_sideband) +
> + sizeof(seg->hw.mm2s_status) +
> + sizeof(seg->hw.app);
> + return &seg->hw.mm2s_ctrl_sideband;
> + }
> +
> struct xilinx_axidma_tx_segment *seg;
>
> - *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
> - seg = list_first_entry(&desc->segments,
> - struct xilinx_axidma_tx_segment, node);
> + if (chan->direction == DMA_DEV_TO_MEM)
> + seg = list_last_entry(&desc->segments,
> + struct xilinx_axidma_tx_segment, node);
> + else
> + seg = list_first_entry(&desc->segments,
> + struct xilinx_axidma_tx_segment, node);
> +
> + *max_len = *payload_len = sizeof(seg->hw.app);
> return seg->hw.app;
> }
>
> @@ -2639,6 +2673,9 @@ xilinx_mcdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> segment->hw.control |= XILINX_MCDMA_BD_EOP;
> }
>
> + if (chan->xdev->has_axistream_connected)
> + desc->async_tx.metadata_ops = &xilinx_dma_metadata_ops;
> +
> return &desc->async_tx;
>
> error:
> @@ -3287,7 +3324,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
>
> dma_set_max_seg_size(xdev->dev, xdev->max_buffer_len);
>
> - if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
> + if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA ||
> + xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> xdev->has_axistream_connected =
> of_property_read_bool(node, "xlnx,axistream-connected");
> }
^ permalink raw reply
* Re: [PATCH net-next v8 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Lorenzo Bianconi @ 2026-07-17 11:20 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, Alexander Lobakin, linux-arm-kernel, linux-mediatek,
netdev, Madhur Agrawal
In-Reply-To: <20260703-airoha-ethtool-priv_flags-v8-0-015ba5ac89ee@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3833 bytes --]
> Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
> offload is created or destroyed.
> Make dev->qdma an RCU pointer so the TX path can safely dereference it
> without holding RTNL.
> Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
>
> ---
> Changes in v8:
> - Rebase on top of next-next to fix conflicts.
> - Link to v7: https://lore.kernel.org/r/20260701-airoha-ethtool-priv_flags-v7-0-b4153bd44428@kernel.org
>
> Changes in v7:
> - Fix ETS stats accounting in patch 2/3
> - Reset ETS stats accounting in airoha_dev_set_qdma().
> - Link to v6: https://lore.kernel.org/r/20260629-airoha-ethtool-priv_flags-v6-0-86bc600d31bc@kernel.org
>
> Changes in v6:
> - Rebase on top of next-next
> - Add patch 1/3: "rename airoha_priv_flags to airoha_dev_flags"
> - Drop patch 2/3: "refactor QDMA start/stop into reusable helpers"
> - Link to v5: https://lore.kernel.org/r/20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org
>
> Changes in v5:
> - Add patch 1/3: use int instead of atomic_t for qdma users counter
> - Protect dev->flags with flow_offload_mutex mutex.
> - Introduce AIROHA_PRIV_F_QOS in order to handle better WAN/LAN
> switching.
> - Link to v4: https://lore.kernel.org/r/20260610-airoha-ethtool-priv_flags-v4-0-60e89cf28fea@kernel.org
>
> Changes in v4:
> - Move back QDMA TX/RX DMA enable to airoha_dev_open()/airoha_dev_stop().
> - Configure GDM3/4 as WAN if GDM2 is not available in ndo_init()
> callback.
> - Protect qdma pointer in airoha_gdm_dev struct using RCU.
> - Rely on rtnl_dereference() to access qdma pointer in the control path.
> - Add airoha_qdma_start() and airoha_qdma_stop() utility routines in
> patch 1/2
> - Link to v3: https://lore.kernel.org/r/20260608-airoha-ethtool-priv_flags-v3-1-3e8e3dc3f715@kernel.org
>
> Changes in v3:
> - Do not introduce ethtool private flags support to configure LAN/WAN
> for GDM3/4 and rely on tc qdisc offload for it instead.
> - Set GDM3/4 ports as LAN by default.
> - Move QDMA TX/RX DMA enable from airoha_dev_open() to airoha_probe()
> and the corresponding disable from airoha_dev_stop() to airoha_qdma_cleanup().
> - Link to v2: https://lore.kernel.org/r/20260607-airoha-ethtool-priv_flags-v2-1-742c7aa1e182@kernel.org
>
> Changes in v2:
> - Rework airoha_dev_set_wan_flag routine
> - Enable GDM_STRIP_CRC_MASK in airoha_disable_gdm2_loopback()
> - Do not always reset REG_SRC_PORT_FC_MAP6 in
> airoha_disable_gdm2_loopback() but use the same condition used in
> airoha_enable_gdm2_loopback().
> - Link to v1: https://lore.kernel.org/r/20260606-airoha-ethtool-priv_flags-v1-1-401b2c9fe9f1@kernel.org
Hi all,
I noticied this series, even if it is properly acked/reviewed, it is marked as
'New, archived' in patchwork:
https://patchwork.kernel.org/project/netdevbpf/cover/20260703-airoha-ethtool-priv_flags-v8-0-015ba5ac89ee@kernel.org/
I'm not entirely sure what the next steps should be for this series.
Thanks in advance.
Regards,
Lorenzo
>
> ---
> Lorenzo Bianconi (3):
> net: airoha: rename airoha_priv_flags to airoha_dev_flags
> net: airoha: fix ETS QoS stats counter underflow and cross-channel corruption
> net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
>
> drivers/net/ethernet/airoha/airoha_eth.c | 253 ++++++++++++++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 26 ++-
> drivers/net/ethernet/airoha/airoha_ppe.c | 9 +-
> drivers/net/ethernet/airoha/airoha_regs.h | 1 +
> 4 files changed, 246 insertions(+), 43 deletions(-)
> ---
> base-commit: 6fb33632323a396c9dc2bb9bea483e013e547d57
> change-id: 20260606-airoha-ethtool-priv_flags-b6aa70caa780
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v1] llc: fix SAP refcount leak when creating incoming sockets
From: patchwork-bot+netdevbpf @ 2026-07-17 11:20 UTC (permalink / raw)
To: luoxuanqiang
Cc: netdev, davem, edumazet, kuba, pabeni, horms, linux-kernel,
opurdila, tim.bird, luoxuanqiang, stable
In-Reply-To: <20260712130343.518797-1-xuanqiang.luo@linux.dev>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Jul 2026 21:03:43 +0800 you wrote:
> From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>
> llc_sap_add_socket() takes a SAP reference for each socket added to a SAP,
> and llc_sap_remove_socket() releases it. llc_create_incoming_sock() takes
> an additional SAP reference after adding the child socket.
>
> This extra reference was balanced by an explicit llc_sap_put() in
> llc_ui_release() until commit 3100aa9d74db ("llc: fix SAP reference
> counting w.r.t. socket handling") removed that put. The corresponding hold
> in the accept path was left behind.
>
> [...]
Here is the summary with links:
- [net,v1] llc: fix SAP refcount leak when creating incoming sockets
https://git.kernel.org/netdev/net/c/2c72eb628634
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] selftests: netconsole: only restore MAC when it changed on resume
From: patchwork-bot+netdevbpf @ 2026-07-17 11:20 UTC (permalink / raw)
To: Andre Carvalho
Cc: leitao, andrew+netdev, davem, edumazet, kuba, pabeni, shuah,
netdev, linux-kselftest, linux-kernel, matttbe
In-Reply-To: <20260710-netcons-mac-reload-v1-1-3fb1bcc70b4a@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 10 Jul 2026 23:19:17 +0100 you wrote:
> The "mac" bind mode reactivation downs the interface, restores the saved
> MAC and renames it to trigger a target resume. This assumes the recreated
> interface comes back with a different MAC, which is true under
> MACAddressPolicy=none (as on the Netdev CI) but not when MACs are
> persistent. In the persistent case netconsole resumes the target on its
> own, and the down/restore/rename flow instead drops it and fails the test.
>
> [...]
Here is the summary with links:
- [net] selftests: netconsole: only restore MAC when it changed on resume
https://git.kernel.org/netdev/net/c/04aeddf2dadd
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: add preliminary support to configure tx hw QoS queue during flowtable offloading
From: patchwork-bot+netdevbpf @ 2026-07-17 11:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260703-airoha-hw-qos-queue-stub-v1-1-ef253ffdd093@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 03 Jul 2026 13:02:17 +0200 you wrote:
> Add the plumbing to program the AIROHA_FOE_QID field in the PPE FOE
> entry with a per-flow priority value during flowtable offload. This
> allows the hardware to steer offloaded flows to a specific QoS queue
> on the egress QDMA block for traffic forwarded between two interfaces
> via hardware acceleration, bypassing the kernel forwarding path.
> The priority parameter is currently always zero because netfilter does
> not yet provide a mechanism to pass the skb priority field to the
> flowtable offload driver. Once that support is added in the netfilter
> subsystem, the driver will be able to extract the priority from the
> flow rule and map it to the appropriate hardware queue.
>
> [...]
Here is the summary with links:
- [net-next] net: airoha: add preliminary support to configure tx hw QoS queue during flowtable offloading
https://git.kernel.org/netdev/net-next/c/9df92875d6d7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: pse-pd: guard regulator ops against freed PI data during unregister
From: Simon Horman @ 2026-07-17 11:10 UTC (permalink / raw)
To: github
Cc: Simon Horman, o.rempel, kory.maincent, andrew+netdev, davem,
edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260711121611.1639086-3-github@szelinsky.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
https://sashiko.dev/#/patchset/20260711121611.1639086-2-github@szelinsky.de?part=2
---
--- Patch [2]: [PATCH net v2 2/2] net: pse-pd: guard regulator ops against freed PI data during unregister ---
commit 651be76b54426e6621f4330232053b29d0731f5d
Author: Carlo Szelinsky <github@szelinsky.de>
net: pse-pd: guard regulator ops against freed PI data during unregister
The commit tries to fix a use-after-free by clearing pcdev->pi to NULL under
pcdev->lock during unregister, and adding NULL checks in the regulator
operations.
[Severity: High]
This is a pre-existing issue, but could the entire pcdev object be used after
free because the API fails to establish a stateful device link between the PSE
controller and the consumer?
If the supplier driver is unbound (e.g., via sysfs or hot-unplug), the memory
backing pcdev is freed via devres. Because of_pse_control_get() acquires the
control without adding a device link (device_link_add) to ensure the supplier
cannot be unbound:
of_pse_control_get()
psec = pse_control_get_internal(pcdev, psec_id, phydev);
The network device continues to hold a dangling psec->pcdev pointer, and
subsequent ethtool requests dereference the freed pcdev:
pse_ethtool_get_status()
pcdev = psec->pcdev;
ops = pcdev->ops;
[Severity: High]
This is a pre-existing issue, but does error handling in pse_register_pw_ds()
leak xa_alloc entries, leading to a use-after-free on a subsequent driver
reload?
If pse_register_pw_ds() succeeds in allocating a power domain via
devm_pse_alloc_pw_d():
devm_pse_alloc_pw_d()
ret = xa_alloc(&pse_pw_d_map, &index, pw_d, XA_LIMIT(1,
PSE_PW_D_LIMIT), GFP_KERNEL);
But fails on a later iteration, it bails out without cleaning up previously
allocated and mapped pw_d instances:
pse_register_pw_ds()
pw_d = devm_pse_alloc_pw_d(pcdev->dev);
if (IS_ERR(pw_d)) {
ret = PTR_ERR(pw_d);
goto out;
}
The devm-managed pointer remains in the global xarray after devres frees it.
The next time the driver probes, xa_for_each(&pse_pw_d_map, ...) will access
the freed pw_d->supply pointer.
[Severity: High]
Does this patch series introduce a disable_irq() operation on an already
freed IRQ during devres unwind?
Devres unwinds resources in LIFO order. In drivers like tps23881.c, the devres
order is established where the controller is registered before the IRQ is
requested:
tps23881_i2c_probe()
ret = devm_pse_controller_register(dev, &priv->pcdev);
if (ret) {
return dev_err_probe(dev, ret, "failed to register PSE controller\n");
}
ret = tps23881_setup_irq(priv, client->irq);
On driver detach, the IRQ is freed first. Then devm_pse_controller_release()
runs and calls pse_controller_unregister(), which calls disable_irq() on an
IRQ that was already freed:
pse_controller_unregister()
if (pcdev->irq)
disable_irq(pcdev->irq);
> diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
> index 6045b6c399c26..21ccb51466160 100644
> --- a/drivers/net/pse-pd/pse_core.c
> +++ b/drivers/net/pse-pd/pse_core.c
> @@ -144,7 +144,13 @@ static void pse_release_pis(struct pse_controller_dev *pcdev)
> of_node_put(pcdev->pi[i].pairset[1].np);
> of_node_put(pcdev->pi[i].np);
> }
> + /* Free under the lock so the NULL store is authoritative against
> + * the regulator ops that read pcdev->pi under pcdev->lock.
> + */
> + mutex_lock(&pcdev->lock);
> kfree(pcdev->pi);
> + pcdev->pi = NULL;
[Severity: High]
Does setting pcdev->pi to NULL without guarding consumer paths convert a
use-after-free into a deterministic NULL pointer dereference?
For example, a network consumer holding a pse_control reference can call
ethtool status, which evaluates the pointer from the NULL pcdev->pi and
dereferences it:
pse_ethtool_get_status()
pi = &pcdev->pi[psec->id];
mutex_lock(&pcdev->lock);
if (pi->pw_d) {
Similarly, __pse_control_release() unconditionally accesses pcdev->pi
completely unguarded:
__pse_control_release()
if (psec->pcdev->pi[psec->id].admin_state_enabled)
regulator_disable(psec->ps);
[Severity: High]
Could freeing and NULLing pcdev->pi here while the controller is still
globally visible cause a race condition with of_pse_control_get()?
pse_controller_unregister() calls pse_release_pis(), and only later removes
the controller from the globally visible list:
pse_controller_unregister()
pse_release_pis(pcdev);
kfifo_free(&pcdev->ntf_fifo);
mutex_lock(&pse_list_mutex);
list_del(&pcdev->list);
Concurrently, of_pse_control_get() can iterate the list and call
of_pse_match_pi(), which dereferences the NULL pcdev->pi array:
of_pse_match_pi()
for (i = 0; i < pcdev->nr_lines; i++) {
if (pcdev->pi[i].np == np)
> + mutex_unlock(&pcdev->lock);
> }
>
> /**
[ ... ]
> @@ -702,15 +718,20 @@ static int pse_pi_enable(struct regulator_dev *rdev)
> static int pse_pi_disable(struct regulator_dev *rdev)
> {
> struct pse_controller_dev *pcdev = rdev_get_drvdata(rdev);
> - struct pse_pi *pi;
> int id, ret;
>
> id = rdev_get_id(rdev);
> - pi = &pcdev->pi[id];
> mutex_lock(&pcdev->lock);
[Severity: High]
This is a pre-existing issue, but is there a race condition between
pse_flush_pw_ds() and pse_pi_disable() that causes a use-after-free of the
regulator supply?
pse_flush_pw_ds() drops the power domain refcount, which leads to
regulator_put() freeing the regulator object. This is done without holding
pcdev->lock:
pse_flush_pw_ds()
kref_put_mutex(&pw_d->refcnt, __pse_pw_d_release, &pse_pw_d_mutex);
Concurrently, if the regulator core's delayed disable worker invokes
pse_pi_disable(), it can see a non-NULL pcdev->pi, proceed to call
_pse_pi_disable(), and eventually call pse_pi_deallocate_pw_budget().
pse_pi_deallocate_pw_budget() then attempts to dereference the freed regulator
supply:
pse_pi_deallocate_pw_budget()
regulator_free_power_budget(pi->pw_d->supply, pi->pw_allocated_mW);
> + /* Reached via the regulator core's deferred-disable flush after
> + * pcdev->pi is freed on unregister.
> + */
> + if (!pcdev->pi) {
> + mutex_unlock(&pcdev->lock);
> + return 0;
> + }
> ret = _pse_pi_disable(pcdev, id);
> if (!ret)
> - pi->admin_state_enabled = 0;
> + pcdev->pi[id].admin_state_enabled = 0;
>
> mutex_unlock(&pcdev->lock);
> return 0;
^ permalink raw reply
* Re: [PATCH net] mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n
From: patchwork-bot+netdevbpf @ 2026-07-17 11:30 UTC (permalink / raw)
To: Weiming Shi
Cc: davem, edumazet, kuba, pabeni, horms, dsahern, kuniyu, gnault,
xmei5, netdev, linux-kernel
In-Reply-To: <20260711114958.1009619-3-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 11 Jul 2026 04:50:00 -0700 you wrote:
> On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed
> attribute table itself instead of calling ip_valid_fib_dump_req(). The
> RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is
> present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no
> RTA_OIF hits a NULL dereference.
>
> RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without
> CAP_NET_ADMIN, so an unprivileged user can trigger it.
>
> [...]
Here is the summary with links:
- [net] mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n
https://git.kernel.org/netdev/net/c/56d96fededd6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: mana: Add debug knob to skip TX timeout recovery reset
From: patchwork-bot+netdevbpf @ 2026-07-17 11:30 UTC (permalink / raw)
To: Aditya Garg
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, horms, ernis, dipayanroy,
ssengar, gargaditya, linux-hyperv, netdev, linux-kernel,
linux-rdma
In-Reply-To: <20260710132229.2851441-1-gargaditya@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 10 Jul 2026 06:22:29 -0700 you wrote:
> Add a per-port debugfs boolean "tx_timeout_skip_reset" that, when
> enabled, makes mana_tx_timeout() log the TX timeout and return without
> queueing the per-port detach/attach recovery work.
>
> This is a debug-only aid for bringup and qualification: skipping the
> recovery reset keeps the device and queue state intact so a TX timeout
> can be correlated with hardware telemetry. The knob defaults to false,
> so production recovery behaviour is unchanged.
>
> [...]
Here is the summary with links:
- [net-next] net: mana: Add debug knob to skip TX timeout recovery reset
https://git.kernel.org/netdev/net-next/c/922cc43c6243
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] mac802154: hold an interface reference across the scan worker
From: Miquel Raynal @ 2026-07-17 11:37 UTC (permalink / raw)
To: Ibrahim Hashimov
Cc: alex.aring, stefan, linux-wpan, netdev, linux-kernel, stable
In-Reply-To: <20260717105810.26226-1-security@auditcode.ai>
Hello,
> Fixes: 57588c71177f ("mac802154: Handle passive scanning")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
> Assisted-by: AuditCode-AI:2026.07
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox