* Re: [PATCH v2] fix: net: renesas: rswitch_mii_register: fix double of_node_put after of_mdiobus_register
From: WenTao Liang @ 2026-06-27 11:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Yoshihiro Shimoda, David S . Miller, Jakub Kicinski,
Paolo Abeni, stable, linux-kernel
In-Reply-To: <fdb2120d-5d0e-445f-97a5-ef2307ebd4d1@lunn.ch>
> 2026年6月27日 00:10，Andrew Lunn <andrew@lunn.ch> 写道：
>
> On Fri, Jun 26, 2026 at 11:25:50PM +0800, WenTao Liang wrote:
>> After of_mdiobus_register succeeds, the mdio_np reference ownership is
>> transferred to the mii_bus device (released via fwnode_handle_put during
>> mdiobus_release). The success path calls of_node_put(mdio_np) which,
>> combined with the automatic release via bus teardown, results in a double
>> put and refcount underflow.
>>
>> Move of_node_put so it is only called in the error path where
>> of_mdiobus_register failed. On success, the bus driver manages the
>> reference lifecycle.
>
> Please stop with these patches.
>
> First please read:
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> and
>
> https://docs.kernel.org/process/submitting-patches.html
>
> You are getting a lot of things wrong.
>
> * don’t repost your patches within one 24h period
> * Don't thread new versions of a patch to the old one
> * Include version history, how is v2 different to v1
> * When you see your own patch is broken, reply with NACK, and explain
> what is wrong with it.
>
> Until you learn how to correctly submit patches, please only submit
> them one at a time, get it accepted, and move onto the next. Otherwise
> you are wasting peoples time, and getting yourself a bad reputation.
>
> Andrew
Hi Andrew,
Thank you for your careful review and for pointing out this issue. You are
absolutely correct — my previous analysis was flawed, and I appreciate you
taking the time to clarify.
Let me address your concerns:
1. On the double of_node_put():
You are right. In the current error path, if mdiobus_register() succeeds
and later macb_mii_probe() fails, the code jumps to err_out_unregister_bus,
which calls mdiobus_unregister() and then mdiobus_free().
- mdiobus_free() indeed releases the reference to the device node (via
put_device()).
- Adding an explicit of_node_put() in that same path would indeed result
in a double decrement, which is incorrect and could lead to use-after-free
or refcount underflow.
2. On the risk of untested patches:
You are right to be cautious. I do not have access to the specific hardware
to test this change, and I should have been more careful in reasoning about
the reference counting semantics. I will refrain from submitting further
patches in this area without proper testing or more thorough review of the
existing code paths.
3. Proposed way forward:
I will withdraw this patch for now. If I find a way to test it or gain more
confidence through static analysis and documentation, I will resubmit with
a clearer explanation and, ideally, test results.
Again, thank you for your diligence. I apologize for the noise and any extra
work this may have caused.
Please let me know if there is anything else I can clarify or help with.
Best regards,
WenTao Liang
^ permalink raw reply
* Re: [PATCH net v4 2/2] net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
From: Maxime Chevallier @ 2026-06-27 12:03 UTC (permalink / raw)
To: Petr Wozniak, olek2, linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
bjorn, kabel
In-Reply-To: <20260626163519.10678-1-petr.wozniak@gmail.com>
Hi Petr
On 6/26/26 18:35, Petr Wozniak wrote:
> Maxime Chevallier wrote:
>> I finally got time to test this with a RollBall module, and I
>> confirm what Aleksander says, the RollBall module's PHY doesn't
>> get detected even with this patch. It does work on v7.0 though,
>> so before the bridge probing was introduced.
>
> Thanks a lot for taking the time to test, Maxime - and Aleksander
> for the original report.
>
> That settles it: the deferred-probe approach in patch 2/2 doesn't
> actually restore genuine RollBall PHY detection, and as you both
> confirm it worked before 8fe125892f40 introduced the bridge probing.
> Sashiko's static review flagged the same thing (the probe bypasses the
> PHY discovery retry loop for slow-initializing modules), so the static
> analysis and the two hardware reports all point at the same flaw.
>
> I only have RTL8261BE-based copper modules here, not a genuine RollBall
> one, so I can't develop and verify a proper slow-init timing fix
> (module_t_wait / a retry that waits for the bridge) without the
> hardware to test against.
>
> Given that, my suggestion:
>
> - Please drop patch 2/2 from the series.
>
> - Since 8fe125892f40 regressed genuine RollBall detection and the
> deferred probe doesn't restore it, I think the cleanest fix is to
> revert 8fe125892f40. I'm happy to send that revert if you'd prefer.
> The 5-minute RTL8261BE probe loop it was addressing is handled in our
> downstream tree, so reverting it upstream is fine on our side.
>
> - Patch 1/2 (the mii_bus leak fix) is independent of all this and
> already has Reviewed-by from Maxime and Larysa - it would be good to
> take that one regardless. I can resend it standalone if that's easier.
>
> A proper fix covering slow-firmware modules really needs a genuine
> RollBall module to validate, so it's better owned by someone who has
> that hardware - happy to help review.
>
I only have a single rollball module here, and none with the missing
bridge, so I can't test the full thing either.
In that case, I agree with reverting 8fe125892f40 as this is breaking
all rollball modules right now.
Can you send the revert ?
Maxime
^ permalink raw reply
* [PATCH v4] net: stmmac: fix fatal bus error on resume by reinitializing RX buffers
From: Ding Hui @ 2026-06-27 12:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Maxime Chevallier, Ding Hui,
open list:STMMAC ETHERNET DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: xiasanbo, yangchen11, liuxuanjun
From: Ding Hui <dinghui@lixiang.com>
On suspend, stmmac_suspend() calls stmmac_disable_all_queues() which
stops the RX NAPI, but the RX DMA engine may still be running for a
short window before stmmac_stop_all_dma() takes effect. During that
window the hardware can write incoming frames into the buffers pointed
to by the RX descriptors and write back the descriptors (clearing the
OWN bit and overwriting RDES0/1/2 with status/timestamp data). Because
NAPI is already disabled, the driver never refills these descriptors,
so the RX ring is left in a "consumed but not refilled" state with
stale content in the descriptor buffer-address fields.
On resume, stmmac_clear_descriptors() only re-arms the OWN bit and
does not repopulate the RX buffer address fields. When the DMA is
restarted it dereferences these stale addresses and triggers a fatal
bus error (not kernel panic, just a Fatal Bus Error interrupt and
RX DMA engine halts).
Fix this by introducing stmmac_reinit_rx_descriptors(), called from
stmmac_resume() immediately after stmmac_clear_descriptors(). The
helper iterates every RX descriptor slot and re-programs its buffer
address fields:
- For normal (page_pool) queues: restore RDES0/1 from buf->addr and
RDES2 from buf->sec_addr. The DMA mapping has remained valid across
suspend/resume because no pages were freed. Slots left NULL by a
prior GFP_ATOMIC failure in stmmac_rx_refill() before suspend
are re-allocated here with GFP_KERNEL;
-ENOMEM is returned and resume is aborted if allocation fails.
The slots with null buffer are unacceptable, because they will
cause a DMA suspend dead lock problem by the condition of
Current Descriptor Pointer == Descriptor Tail Pointer.
- For AF_XDP zero-copy queues: restore the DMA address from
xsk_buff_xdp_get_dma(buf->xdp). Slots with no xdp buffer
(e.g. TX-only socket, empty fill ring) attempt xsk_buff_alloc()
first; on failure the descriptor is zeroed so the DMA engine skips
the slot safely via an RBU event.
- For chain mode: call stmmac_mode_init() to rebuild the des3 next-
descriptor pointer chain, which hardware may have overwritten with
a PTP timestamp value (as noted in chain_mode.c:refill_desc3()).
After reprogramming all address fields, a final pass restores OWN=1
on every valid slot. This is necessary because set_sec_addr and
chain-mode init unconditionally overwrite des3 (clearing the OWN bit
set by stmmac_clear_descriptors()), and must run after all address
writes are complete.
Also fix stmmac_init_rx_buffers() to actually use its gfp_t flags
parameter instead of the hardcoded GFP_ATOMIC | __GFP_NOWARN.
Signed-off-by: Ding Hui <dinghui@lixiang.com>
---
Changes in v4:
- Just add description for return value of 'stmmac_reinit_rx_descriptors'.
- Link to v3:
https://lore.kernel.org/netdev/20260604144557.3175399-1-dinghui1111@163.com/
Changes in v3:
- Re-allocate page_pool NULL slots (from prior GFP_ATOMIC failures)
with GFP_KERNEL in stmmac_reinit_rx_descriptors(); return -ENOMEM and
abort resume.
- For XSK NULL slots, attempt xsk_buff_alloc() first; fall back to
stmmac_clear_desc() only when allocation fails.
- Add a re-arm loop at the end of stmmac_reinit_rx_descriptors() to
restore OWN=1 on all valid slots, since set_sec_addr and
chain-mode init both write des3 unconditionally.
- stmmac_reinit_rx_descriptors() now returns int; stmmac_resume()
checks the return value and propagates -ENOMEM with mutex/rtnl cleanup.
- Fix stmmac_init_rx_buffers() to use its flags parameter instead of
hardcoded GFP_ATOMIC | __GFP_NOWARN.
(884d2b845477 ("net: stmmac: Add GFP_DMA32 for rx buffers if no 64
capability"))
- Run stmmac_reinit_rx_descriptors() after stmmac_clear_descriptors()
so that stmmac_clear_desc() on XSK NULL slots overrides the OWN
bit set by stmmac_clear_descriptors().
- Update commit message.
- Link to v2:
https://lore.kernel.org/netdev/20260526022620.501229-1-dinghui1111@163.com/
Changes in v2:
- Introducing stmmac_reinit_rx_descriptors() to reinitializing rx
buffers without any allocation.
- Modify commit log.
- Link to v1:
https://lore.kernel.org/netdev/20260515053856.2310369-1-dinghui1111@163.com/
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 164 +++++++++++++++++-
1 file changed, 163 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3591755ea30b..c82f3d5dbd43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1660,7 +1660,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
{
struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
- gfp_t gfp = (GFP_ATOMIC | __GFP_NOWARN);
+ gfp_t gfp = flags;
if (priv->dma_cap.host_dma_width <= 32)
gfp |= GFP_DMA32;
@@ -1693,6 +1693,148 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
return 0;
}
+/**
+ * stmmac_reinit_rx_descriptors - re-program RX descriptor buffer addresses
+ * after stmmac_clear_descriptors()
+ * @priv: driver private structure
+ * @dma_conf: structure holding the dma data
+ * @queue: RX queue index
+ *
+ * Description: Called in the resume path after stmmac_clear_descriptors()
+ * has re-armed the OWN bit on every descriptor. Walk buf_pool[] and
+ * re-program the buffer-address fields of every RX descriptor from the
+ * buffers that are already attached to the queue. Slots whose page was
+ * never allocated (GFP_ATOMIC failure before suspend) are re-allocated
+ * here with GFP_KERNEL; the resume path is in process context.
+ *
+ * Between suspend and resume the hardware may have written back status/
+ * length information into the descriptor address fields (RDESx are reused
+ * for status on completion for GMAC4/XGMAC), so the address fields must be
+ * repopulated before the DMA is restarted.
+ *
+ * For XSK slots that have no xdp buffer at suspend time (TX-only socket,
+ * empty fill ring for Rx), xsk_buff_alloc() is attempted but does not
+ * return an error on failure because we can't identify a real TX-only
+ * socket from an alloc error (same as stmmac_alloc_rx_buffers_zc() in
+ * __init_dma_rx_desc_rings); on failure the descriptor is zeroed so the DMA
+ * engine skips the slot safely.
+ *
+ * To avoid the DMA stall after resume in non-XSK mode, this function
+ * re-allocates pages for NULL slots using GFP_KERNEL (the resume path runs
+ * in process context). If allocation fails, -%ENOMEM is returned immediately
+ * and the resume is aborted; the caller should report the error.
+ *
+ * This helper must be called after stmmac_clear_descriptors() and before
+ * stmmac_hw_setup() in stmmac_resume() because we need to wipe the OWN bit
+ * set in stmmac_clear_descriptors() for NULL slots in XSK mode.
+ *
+ * Returns: 0 on success, or a negative errno on allocation failure in
+ * non-XSK mode (e.g. -%ENOMEM).
+ */
+static int stmmac_reinit_rx_descriptors(struct stmmac_priv *priv,
+ struct stmmac_dma_conf *dma_conf,
+ u32 queue)
+{
+ struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
+ struct stmmac_rx_buffer *buf;
+ struct dma_desc *p;
+ int i;
+
+ if (rx_q->xsk_pool) {
+ for (i = 0; i < dma_conf->dma_rx_size; i++) {
+ buf = &rx_q->buf_pool[i];
+ p = stmmac_get_rx_desc(priv, rx_q, i);
+
+ /* The XSK pool may not be fully populated (e.g.
+ * xdpsock TX-only, empty fill ring). Try to refill
+ * from the pool; on failure zero the descriptor so the
+ * DMA engine skips this slot safely.
+ */
+ if (!buf->xdp) {
+ buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+ if (!buf->xdp) {
+ stmmac_clear_desc(priv, p);
+ continue;
+ }
+ }
+
+ stmmac_set_desc_addr(priv, p,
+ xsk_buff_xdp_get_dma(buf->xdp));
+ stmmac_set_desc_sec_addr(priv, p, 0, false);
+ }
+ } else {
+ for (i = 0; i < dma_conf->dma_rx_size; i++) {
+ buf = &rx_q->buf_pool[i];
+ p = stmmac_get_rx_desc(priv, rx_q, i);
+
+ /* buf->page can be NULL when stmmac_rx_refill() hit a
+ * GFP_ATOMIC failure before suspend and left the slot
+ * without a buffer. The resume path runs in process
+ * context, so re-allocate with GFP_KERNEL. Allocation
+ * failure aborts the resume.
+ */
+ if (!buf->page) {
+ int err;
+
+ err = stmmac_init_rx_buffers(priv, dma_conf, p,
+ i, GFP_KERNEL,
+ queue);
+ if (err)
+ return err;
+ /* stmmac_init_rx_buffers() already programmed
+ * the descriptor; skip the reprogramming below.
+ */
+ continue;
+ }
+
+ stmmac_set_desc_addr(priv, p, buf->addr);
+ stmmac_set_desc_sec_addr(priv, p, buf->sec_addr,
+ priv->sph_active &&
+ buf->sec_page);
+
+ if (dma_conf->dma_buf_sz == BUF_SIZE_16KiB)
+ stmmac_init_desc3(priv, p);
+ }
+ }
+
+ /* Chain mode: re-link descriptor 'next' pointers. This is
+ * allocation-free; it just rewrites the per-descriptor next
+ * field which may have been clobbered by HW writeback.
+ */
+ if (priv->descriptor_mode == STMMAC_CHAIN_MODE) {
+ void *des = priv->extend_desc ? (void *)rx_q->dma_erx
+ : (void *)rx_q->dma_rx;
+
+ stmmac_mode_init(priv, des, rx_q->dma_rx_phy,
+ dma_conf->dma_rx_size, priv->extend_desc);
+ }
+
+ /* Re-arm OWN=1 on every valid slot.
+ *
+ * Two address-programming helpers write des3 unconditionally and
+ * therefore clear the OWN bit that stmmac_clear_descriptors() set:
+ *
+ * - stmmac_desc_ops.set_sec_addr (called by stmmac_set_desc_sec_addr()):
+ * writes des3 with upper_32_bits(addr).
+ *
+ * - stmmac_mode_ops.init() (called by stmmac_mode_init() above): writes
+ * des3 with the next-descriptor physical address.
+ *
+ * A single pass over valid slots restores OWN=1 after all descriptor
+ * fields have been written. NULL slots are left with OWN=0 for XSK mode
+ * so the Rx DMA engine stalls safely.
+ */
+ for (i = 0; i < dma_conf->dma_rx_size; i++) {
+ buf = &rx_q->buf_pool[i];
+ p = stmmac_get_rx_desc(priv, rx_q, i);
+
+ if (rx_q->xsk_pool ? !!buf->xdp : !!buf->page)
+ stmmac_set_rx_owner(priv, p, false);
+ }
+
+ return 0;
+}
+
/**
* stmmac_free_rx_buffer - free RX dma buffers
* @priv: private structure
@@ -8272,6 +8414,7 @@ int stmmac_resume(struct device *dev)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
+ u32 queue;
int ret;
if (priv->plat->resume) {
@@ -8321,6 +8464,25 @@ int stmmac_resume(struct device *dev)
stmmac_free_tx_skbufs(priv);
stmmac_clear_descriptors(priv, &priv->dma_conf);
+ /* Re-program the RX descriptor buffer-address fields. Slots that
+ * had no page at suspend time (GFP_ATOMIC failure) are re-allocated
+ * here with GFP_KERNEL; XSK slots without an xdp buffer are refilled
+ * from the pool if possible. Any unrecoverable allocation failure
+ * is reported so the resume can be aborted cleanly.
+ */
+ for (queue = 0; queue < priv->plat->rx_queues_to_use; queue++) {
+ ret = stmmac_reinit_rx_descriptors(priv, &priv->dma_conf,
+ queue);
+ if (ret) {
+ netdev_err(priv->dev,
+ "%s: rx desc reinit failed on queue %u\n",
+ __func__, queue);
+ mutex_unlock(&priv->lock);
+ rtnl_unlock();
+ return ret;
+ }
+ }
+
ret = stmmac_hw_setup(ndev);
if (ret < 0) {
netdev_err(priv->dev, "%s: Hw setup failed\n", __func__);
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH net-next v8 03/12] net: phylink: add phylink_release_pcs() to externally release a PCS
From: Christian Marangi @ 2026-06-27 12:33 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <a271385e-302d-45c7-a1df-aebd380b427b@bootlin.com>
On Thu, Jun 25, 2026 at 04:13:14PM +0200, Maxime Chevallier wrote:
> Hello Christian,
>
> On 6/18/26 14:57, Christian Marangi wrote:
> > Add phylink_release_pcs() to externally release a PCS from a phylink
> > instance. This can be used to handle case when a single PCS needs to be
> > removed and the phylink instance needs to be refreshed.
> >
> > On calling phylink_release_pcs(), the PCS will be removed from the
> > phylink internal PCS list and the phylink supported_interfaces value is
> > reparsed with the remaining PCS interfaces.
> >
> > Also a phylink resolve is triggered to handle the PCS removal.
> >
> > The flag force_major_config is set to make phylink resolve reconfigure
> > the interface (even if it didn't change).
> > This is needed to handle the special case when the current PCS used
> > by phylink is removed and a major_config is needed to propagae the
> > configuration change. With this option enabled we also force mac_config
> > even if the PHY link is not up for the in-band case.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > drivers/net/phy/phylink.c | 56 +++++++++++++++++++++++++++++++++++++++
> > include/linux/phylink.h | 2 ++
> > 2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index c38bcd43b8c8..064d6f5a06da 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -158,6 +158,8 @@ static const phy_interface_t phylink_sfp_interface_preference[] = {
> > static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
> >
> > static void phylink_run_resolve(struct phylink *pl);
> > +static void phylink_link_down(struct phylink *pl);
> > +static void phylink_pcs_disable(struct phylink_pcs *pcs);
> >
> > /**
> > * phylink_set_port_modes() - set the port type modes in the ethtool mask
> > @@ -918,6 +920,60 @@ static void phylink_resolve_an_pause(struct phylink_link_state *state)
> > }
> > }
> >
> > +/**
> > + * phylink_release_pcs - Removes a PCS from the phylink PCS available list
> > + * @pcs: a pointer to the phylink_pcs struct to be released
> > + *
> > + * This function release a PCS from the phylink PCS available list if
> > + * actually in use. It also refreshes the supported interfaces of the
> > + * phylink instance by copying the supported interfaces from the phylink
> > + * conf and merging the supported interfaces of the remaining available PCS
> > + * in the list and trigger a resolve.
> > + */
> > +void phylink_release_pcs(struct phylink_pcs *pcs)
> > +{
> > + struct phylink *pl;
> > +
> > + ASSERT_RTNL();
> > +
> > + pl = pcs->phylink;
> > + if (!pl)
> > + return;
> > +
> > + mutex_lock(&pl->state_mutex);
> > +
> > + list_del(&pcs->list);
> > + pcs->phylink = NULL;
> > +
> > + /*
> > + * Check if we are removing the PCS currently
> > + * in use by phylink. If this is the case, tear down
> > + * the link, force phylink resolve to reconfigure the
> > + * interface mode, disable the current PCS and set the
> > + * phylink PCS to NULL.
> > + */
> > + if (pl->pcs == pcs) {
> > + phylink_link_down(pl);
> > + phylink_pcs_disable(pl->pcs);
> > +
> > + pl->force_major_config = true;
> > + pl->pcs = NULL;
> > + }
> > +
> > + mutex_unlock(&pl->state_mutex);
> > +
> > + /* Refresh supported interfaces */
> > + phy_interface_copy(pl->supported_interfaces,
> > + pl->config->supported_interfaces);
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + phy_interface_or(pl->supported_interfaces,
> > + pl->supported_interfaces,
> > + pcs->supported_interfaces);
>
> I've given more thought to that 'supported_interfaces' thing. This
> patchset redefines the meaning of
>
> pl->config->supported_interfaces
>
> Currently, it's filled by the MAC driver and means "Every interface
> we can support, including the ones provided by PCSs that we can use
> with this MAC".
>
> It now becomes "Every interface we support without needing a PCS", at
> least the way I understand that.
>
Wait but with the current code using the OR logic, it still follows
"Every interface we can support...". The modes that needs a PCS are
specificed with the pcs_interfaces mask in phylink_config.
The late add and release operates on the phylink supported_interfaces ONLY
when the MAC didn't specify support for it (by removing it as only the PCS
will declare support for it)
The confusion is present because everything is validated later on
major_config so those supported_interfaces are just an HINT that are later
verified with get_caps and with the pcs_validate OPs.
Adding the supported_interfaces to phylink is really to keep an original
reference of the value. This is to address a pattern I have notice where
the MAC driver always OR the interfaces with the one supported by the PCS.
(I remember it was pointed out by Russell)
But I'm more than open to discussion as this is something marginal to the
whole implementation, I'm also questioning if this OR is actually useful to
anything on the nth tought on this.
One thing that I notice is that parsing this early with AND might be
problematic at phylink_create, but I still have to evaluate that.
My take is that would be good to have some review also on the other logic
as I think I reached a point where Sashiko starts to comments on more or
less unreal problem.
> It's not an error in your code, but I think this is worth documenting
> somewhere as this changes one the things that's already fairly
> error-prone in new drivers.
>
> I don't know to what extent people use that, be we have a porting guide
> that explains how to use phylink in a MAC driver, maybe an update in there
> would be nice as well :
>
> https://docs.kernel.org/networking/sfp-phylink.html#rough-guide-to-converting-a-network-driver-to-sfp-phylink
>
> Maxime
>
>
--
Ansuel
^ permalink raw reply
* Re: [PATCH v6 07/10] rust: configfs: use `LocalModule` for `THIS_MODULE`
From: Alvin Sun @ 2026-06-27 13:10 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <DJJ25JJ3TDO9.1UFOP60U0IPX5@garyguo.net>
On 6/26/26 22:41, Gary Guo wrote:
> On Fri Jun 26, 2026 at 3:35 AM BST, Alvin Sun wrote:
>> On 6/25/26 22:40, Gary Guo wrote:
>>> On Wed Jun 24, 2026 at 4:00 PM BST, Alvin Sun wrote:
>>>> Replace the `THIS_MODULE` static reference in the `configfs_attrs!`
>>>> macro with `this_module::<LocalModule>()`, and update
>>>> rnull to import `LocalModule` instead of `THIS_MODULE`, consistent
>>>> with the move of `THIS_MODULE` into the `ModuleMetadata` trait.
>>>>
>>>> Assisted-by: opencode:glm-5.2
>>>> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
>>>> Acked-by: Danilo Krummrich <dakr@kernel.org>
>>>> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
>>>> ---
>>>> drivers/block/rnull/configfs.rs | 6 ++----
>>>> rust/kernel/configfs.rs | 8 +++++---
>>>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
>>>> index c10a55fc58948..b2547ad1e5ddd 100644
>>>> --- a/drivers/block/rnull/configfs.rs
>>>> +++ b/drivers/block/rnull/configfs.rs
>>>> @@ -1,9 +1,7 @@
>>>> // SPDX-License-Identifier: GPL-2.0
>>>>
>>>> -use super::{
>>>> - NullBlkDevice,
>>>> - THIS_MODULE, //
>>>> -};
>>>> +use super::NullBlkDevice;
>>>> +use crate::LocalModule;
>>>> use kernel::{
>>>> block::mq::gen_disk::{
>>>> GenDisk,
>>>> diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
>>>> index 2339c6467325d..c31d7882e216d 100644
>>>> --- a/rust/kernel/configfs.rs
>>>> +++ b/rust/kernel/configfs.rs
>>>> @@ -875,7 +875,7 @@ fn as_ptr(&self) -> *const bindings::config_item_type {
>>>> /// configfs::Subsystem<Configuration>,
>>>> /// Configuration
>>>> /// >::new_with_child_ctor::<N,Child>(
>>>> -/// &THIS_MODULE,
>>>> +/// ::kernel::module::this_module::<crate::LocalModule>(),
>>>> /// &CONFIGURATION_ATTRS
>>>> /// );
>>>> ///
>>>> @@ -1021,7 +1021,8 @@ macro_rules! configfs_attrs {
>>>>
>>>> static [< $data:upper _TPE >] : $crate::configfs::ItemType<$container, $data> =
>>>> $crate::configfs::ItemType::<$container, $data>::new::<N>(
>>>> - &THIS_MODULE, &[<$ data:upper _ATTRS >]
>>>> + $crate::module::this_module::<LocalModule>(),
>>> ^ You only changed one single place. This is still plain `LocalModule`.
>> Initially I wrote it as `crate::LocalModule`, but clippy warned about it. So
>> instead of putting the crate path in the macro body, I added `use
>> crate::LocalModule` in the calling file.
>>
>> ```
>> warning: `crate` references the macro call's crate
>> --> rust/kernel/configfs.rs:1024:59
>> |
>> 1024 | ... $crate::module::this_module::<crate::LocalModule>(),
>> | ^^^^^ help:
>> to reference the macro definition's crate, use: `$crate`
>> |
>> = help: for further information visit
>> https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#crate_in_macro_def
>> = note: `-W clippy::crate-in-macro-def` implied by `-W clippy::all`
>> = help: to override `-W clippy::all` add
>> `#[allow(clippy::crate_in_macro_def)]`
>>
>> warning: 1 warning emitted
>> ```
> Clippy has a point about `crate::` being usually wrong in macros, but it is what
> we actually want here, so obviously you should allow the warning.
>
> It is the exact same case in `vtable` macro, just that Clippy is unable to check
> proc macros!
Thanks for the detailed explanation.
I specifically searched for issues related to `crate_in_macro_def`, and
this information is very useful to me.
Best regards,
Alvin
>
> Best,
> Gary
>
>> Alternatively, `#[allow(clippy::crate_in_macro_def)]` could be added on
>> the macro
>> definition. Would you suggest that approach?
^ permalink raw reply
* [PATCH net] nfc: pn533: fix use-after-free in pn533_recv_frame
From: Yinhao Hu @ 2026-06-27 13:13 UTC (permalink / raw)
To: netdev
Cc: David Heidelberg, Dan Carpenter, Krzysztof Kozlowski, Kees Cook,
Jakub Kicinski, Samuel Ortiz, Michael Thalmeier, dzm91,
hust-os-kernel-patches, Yinhao Hu
pn533_recv_frame() checks dev->cmd and then dereferences it several
times to store the receive status and the response skb. In parallel the
command completion worker runs pn533_send_async_complete(), which frees
the same struct pn533_cmd and only clears dev->cmd after the free. With
fast receive/completion timing the receive path can therefore write to
an already freed command object.
Serialize all accesses to dev->cmd with a new cmd_state_lock spinlock:
pn533_recv_frame() now inspects and updates the current command while
holding the lock, the send paths publish and clear the pointer through
pn533_set_current_cmd(), and the completion worker detaches the command
under the lock before freeing it. Once the worker has detached the command,
a racing receive observes a NULL dev->cmd and no longer touches the freed
object.
BUG: KASAN: slab-use-after-free in pn533_recv_frame+0x54f/0x670
Write of size 4 at addr ffff888105566a14 by task kworker/1:3/126
CPU: 1 UID: 0 PID: 126 Comm: kworker/1:3 Not tainted 7.1.0+ #8 PREEMPT
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: events nfc_urelease_event_work
Call Trace:
<TASK>
dump_stack_lvl+0x8c/0xb0
print_report+0xd0/0x630
kasan_report+0xce/0x100
pn533_recv_frame+0x54f/0x670
pn533_stop_poll+0xdc/0x150
nfc_stop_poll+0xf2/0x1c0
nfc_urelease_event_work+0x194/0x270
process_one_work+0x701/0x1160
worker_thread+0x5e6/0xd50
kthread+0x373/0x4c0
ret_from_fork+0x2e9/0x750
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 1744:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x194/0x430
__pn533_send_async+0x5c/0x410
pn533_wq_rf+0xc6/0x160
process_one_work+0x701/0x1160
worker_thread+0x5e6/0xd50
kthread+0x373/0x4c0
ret_from_fork+0x2e9/0x750
ret_from_fork_asm+0x1a/0x30
Freed by task 1744:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x17b/0x440
pn533_wq_cmd_complete+0x24d/0x450
process_one_work+0x701/0x1160
worker_thread+0x5e6/0xd50
kthread+0x373/0x4c0
ret_from_fork+0x2e9/0x750
ret_from_fork_asm+0x1a/0x30
Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation")
Signed-off-by: Yinhao Hu <dddddd@hust.edu.cn>
---
drivers/nfc/pn533/pn533.c | 47 ++++++++++++++++++++++++++++++++-------
drivers/nfc/pn533/pn533.h | 1 +
2 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index d7bdbc82e2ba..921e93a5f16f 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -394,12 +394,32 @@ static void pn533_build_cmd_frame(struct pn533 *dev, u8 cmd_code,
ops->tx_frame_finish(skb->data);
}
+static void pn533_set_current_cmd(struct pn533 *dev, struct pn533_cmd *cmd)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->cmd_state_lock, flags);
+ dev->cmd = cmd;
+ spin_unlock_irqrestore(&dev->cmd_state_lock, flags);
+}
+
static int pn533_send_async_complete(struct pn533 *dev)
{
- struct pn533_cmd *cmd = dev->cmd;
+ struct pn533_cmd *cmd;
struct sk_buff *resp;
+ unsigned long flags;
int status, rc = 0;
+ /*
+ * Detach the current command before freeing it, so a concurrent
+ * pn533_recv_frame() either observes a valid command under the lock
+ * or a NULL dev->cmd and stops touching the freed object.
+ */
+ spin_lock_irqsave(&dev->cmd_state_lock, flags);
+ cmd = dev->cmd;
+ dev->cmd = NULL;
+ spin_unlock_irqrestore(&dev->cmd_state_lock, flags);
+
if (!cmd) {
dev_dbg(dev->dev, "%s: cmd not set\n", __func__);
goto done;
@@ -430,7 +450,6 @@ static int pn533_send_async_complete(struct pn533 *dev)
done:
kfree(cmd);
- dev->cmd = NULL;
return rc;
}
@@ -458,10 +477,10 @@ static int __pn533_send_async(struct pn533 *dev, u8 cmd_code,
mutex_lock(&dev->cmd_lock);
if (!dev->cmd_pending) {
- dev->cmd = cmd;
+ pn533_set_current_cmd(dev, cmd);
rc = dev->phy_ops->send_frame(dev, req);
if (rc) {
- dev->cmd = NULL;
+ pn533_set_current_cmd(dev, NULL);
goto error;
}
@@ -529,10 +548,10 @@ static int pn533_send_cmd_direct_async(struct pn533 *dev, u8 cmd_code,
pn533_build_cmd_frame(dev, cmd_code, req);
- dev->cmd = cmd;
+ pn533_set_current_cmd(dev, cmd);
rc = dev->phy_ops->send_frame(dev, req);
if (rc < 0) {
- dev->cmd = NULL;
+ pn533_set_current_cmd(dev, NULL);
kfree(cmd);
}
@@ -569,10 +588,10 @@ static void pn533_wq_cmd(struct work_struct *work)
mutex_unlock(&dev->cmd_lock);
- dev->cmd = cmd;
+ pn533_set_current_cmd(dev, cmd);
rc = dev->phy_ops->send_frame(dev, cmd->req);
if (rc < 0) {
- dev->cmd = NULL;
+ pn533_set_current_cmd(dev, NULL);
dev_kfree_skb(cmd->req);
kfree(cmd);
return;
@@ -2165,6 +2184,15 @@ static int pn533_data_exchange_complete(struct pn533 *dev, void *_arg,
*/
void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status)
{
+ unsigned long flags;
+
+ /*
+ * Hold cmd_state_lock across the whole receive path so the current
+ * command cannot be freed by pn533_send_async_complete() between the
+ * dev->cmd check and the stores into it.
+ */
+ spin_lock_irqsave(&dev->cmd_state_lock, flags);
+
if (!dev->cmd)
goto sched_wq;
@@ -2182,6 +2210,7 @@ void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status)
if (pn533_rx_frame_is_ack(skb->data)) {
dev_dbg(dev->dev, "%s: Received ACK frame\n", __func__);
+ spin_unlock_irqrestore(&dev->cmd_state_lock, flags);
dev_kfree_skb(skb);
return;
}
@@ -2200,6 +2229,7 @@ void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status)
dev->cmd->resp = skb;
sched_wq:
+ spin_unlock_irqrestore(&dev->cmd_state_lock, flags);
queue_work(dev->wq, &dev->cmd_complete_work);
}
EXPORT_SYMBOL(pn533_recv_frame);
@@ -2760,6 +2790,7 @@ struct pn533 *pn53x_common_init(u32 device_type,
priv->device_type = device_type;
mutex_init(&priv->cmd_lock);
+ spin_lock_init(&priv->cmd_state_lock);
INIT_WORK(&priv->cmd_work, pn533_wq_cmd);
INIT_WORK(&priv->cmd_complete_work, pn533_wq_cmd_complete);
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index 09e35b8693f5..8b009b2318d0 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -153,6 +153,7 @@ struct pn533 {
struct pn533_cmd *cmd;
u8 cmd_pending;
struct mutex cmd_lock; /* protects cmd queue */
+ spinlock_t cmd_state_lock; /* protects dev->cmd lifetime */
void *cmd_complete_mi_arg;
void *cmd_complete_dep_arg;
--
2.43.0
^ permalink raw reply related
* Question: bridge: clarify MST VLAN list RCU traversal contract
From: Runyu Xiao @ 2026-06-27 13:25 UTC (permalink / raw)
To: Nikolay Aleksandrov, Ido Schimmel
Cc: Runyu Xiao, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, bridge, netdev, linux-kernel,
jianhao.xu
Hi bridge maintainers,
This question comes from a candidate found by our static analysis tool
and then manually reviewed against the current tree. The audit used
CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
for maintainer guidance because the source-level review did not prove
a use-after-free.
A CONFIG_PROVE_RCU_LIST audit flags the VLAN-list traversal in
br_mst_info_size():
net/bridge/br_mst.c:251 br_mst_info_size()
The helper walks vg->vlan_list with list_for_each_entry_rcu(). In the
direct local context, br_get_link_af_size_filtered() first enters an
RCU read-side section, resolves the bridge port or bridge VLAN group,
and calls br_get_num_vlan_infos(vg, filter_mask). That local RCU
read-side section is then dropped before the later MST sizing call:
net/bridge/br_netlink.c:104 rcu_read_lock()
net/bridge/br_netlink.c:113 br_get_num_vlan_infos(vg, filter_mask)
net/bridge/br_netlink.c:114 rcu_read_unlock()
net/bridge/br_netlink.c:123 br_mst_info_size(vg)
The helper is registered through rtnl_af_ops.get_link_af_size, and
bridge VLAN updates appear RTNL-centered, so the broader rtnetlink
sizing path may already provide the intended serialization. I am not
claiming a use-after-free here. The question is only whether the
RCU-list traversal contract around br_mst_info_size() should be made
explicit enough for CONFIG_PROVE_RCU_LIST to see it.
Would you prefer one of these directions?
1. keep the MST sizing loop inside an explicit rcu_read_lock() in
br_get_link_af_size_filtered();
2. pass a confirmed RTNL lockdep condition to the iterator in
br_mst_info_size();
3. document that the outer rtnetlink sizing path is the required
protection and leave the helper unchanged;
4. use a different bridge-specific pattern.
I am intentionally sending this as a maintainer question rather than a
patch because the right contract seems to depend on the bridge/rtnetlink
caller semantics.
Thanks.
^ permalink raw reply
* Question: prestera: clarify event handler RCU-list contract
From: Runyu Xiao @ 2026-06-27 13:50 UTC (permalink / raw)
To: Taras Chornyi
Cc: Runyu Xiao, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, jianhao.xu
Hi Prestera maintainers,
This question comes from a candidate found by our static analysis tool
and then manually reviewed against the current tree. The audit used
CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
for maintainer guidance because the source-level review did not prove
a use-after-free.
A CONFIG_PROVE_RCU_LIST audit flags the shared event-handler lookup
helper:
drivers/net/ethernet/marvell/prestera/prestera_hw.c:923 __find_event_handler()
The receive-side paths use prestera_find_event_handler(), which wraps
the helper in rcu_read_lock(), copies the handler record, and drops RCU
before invoking the callback.
The registration paths call __find_event_handler() directly:
drivers/net/ethernet/marvell/prestera/prestera_hw.c:2255 prestera_hw_event_handler_register()
drivers/net/ethernet/marvell/prestera/prestera_hw.c:2280 prestera_hw_event_handler_unregister()
Registration adds entries with list_add_rcu(). Unregistration removes
entries with list_del_rcu() and frees them with kfree_rcu(). The call
sites look init/fini-style, and I am not claiming a use-after-free here.
The question is only how the non-receive-side lookup contract is meant
to be expressed.
Would you prefer one of these directions?
1. split the helper into an RCU-reader lookup and a registration-time
lookup;
2. wrap the direct register/unregister lookups in a local RCU read-side
section;
3. add an explicit event-handler registration lock if concurrent
register/unregister is possible;
4. document that handler registration is init/fini ordered and leave
the direct helper calls unchanged.
I am intentionally sending this as a maintainer question rather than a
patch because the right shape depends on the intended registration and
teardown model.
Thanks.
^ permalink raw reply
* Re: [syzbot] [net?] BUG: soft lockup in hsr_announce (3)
From: syzbot @ 2026-06-27 15:31 UTC (permalink / raw)
To: andrii, ast, bpf, daniel, davem, eddyz87, edumazet, haoluo, horms,
john.fastabend, jolsa, kpsingh, kuba, linux-kernel, martin.lau,
netdev, pabeni, sdf, song, syzkaller-bugs, yonghong.song
In-Reply-To: <68089c01.050a0220.36a438.0010.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 5a66900afbd6 Merge tag 'drm-fixes-2026-06-27' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10d729fe580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c3d59be33cf7e9a
dashboard link: https://syzkaller.appspot.com/bug?extid=6c68a0400c33951a023c
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=176df861580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-5a66900a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/73461c39cbcb/vmlinux-5a66900a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b8ca145674f8/bzImage-5a66900a.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6c68a0400c33951a023c@syzkaller.appspotmail.com
watchdog: BUG: soft lockup - CPU#0 stuck for 143s! [syz.1.18:5749]
Modules linked in:
irq event stamp: 5276037
hardirqs last enabled at (5276036): [<ffffffff8bb6be38>] irqentry_exit_to_kernel_mode_after_preempt include/linux/irq-entry-common.h:507 [inline]
hardirqs last enabled at (5276036): [<ffffffff8bb6be38>] irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:542 [inline]
hardirqs last enabled at (5276036): [<ffffffff8bb6be38>] irqentry_exit+0x218/0x8f0 kernel/entry/common.c:167
hardirqs last disabled at (5276037): [<ffffffff8bb6abce>] sysvec_apic_timer_interrupt+0xe/0xc0 arch/x86/kernel/apic/apic.c:1062
softirqs last enabled at (7948): [<ffffffff8187eb4a>] __do_softirq kernel/softirq.c:656 [inline]
softirqs last enabled at (7948): [<ffffffff8187eb4a>] invoke_softirq kernel/softirq.c:496 [inline]
softirqs last enabled at (7948): [<ffffffff8187eb4a>] __irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
softirqs last disabled at (7951): [<ffffffff8187eb4a>] __do_softirq kernel/softirq.c:656 [inline]
softirqs last disabled at (7951): [<ffffffff8187eb4a>] invoke_softirq kernel/softirq.c:496 [inline]
softirqs last disabled at (7951): [<ffffffff8187eb4a>] __irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
CPU: 0 UID: 0 PID: 5749 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:unwind_next_frame+0x48e/0x2550 arch/x86/kernel/unwind_orc.c:520
Code: d8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 b4 19 00 00 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 bf 19 00 00 0f b6 43 01 <83> e0 07 0f 84 7c 16 00 00 83 f8 01 4c 8b 6c 24 50 49 bc 00 00 00
RSP: 0018:ffffc90000007480 EFLAGS: 00000246
RAX: 000000000000000b RBX: ffffffff90bf84c6 RCX: ffffffff90462a44
RDX: ffffffff90bf84c2 RSI: ffffffff90bf84c2 RDI: ffffffff8c2ac720
RBP: ffffffff8100012f R08: 0000000000000022 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff8e959c20 R12: dffffc0000000000
R13: ffffffff90bf84c7 R14: ffffc90000007528 R15: ffffffff90462a44
FS: 00007f111b0f96c0(0000) GS:ffff88808c815000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f111a1ea540 CR3: 000000003fc5d000 CR4: 0000000000352ef0
Call Trace:
<IRQ>
arch_stack_walk+0x11b/0x150 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0xa9/0x100 kernel/stacktrace.c:122
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4612 [inline]
slab_alloc_node mm/slub.c:4945 [inline]
kmem_cache_alloc_noprof+0x2a0/0x5f0 mm/slub.c:4959
skb_clone+0x212/0x3a0 net/core/skbuff.c:2110
hsr_forward_do net/hsr/hsr_forward.c:-1 [inline]
hsr_forward_skb+0xfbe/0x28c0 net/hsr/hsr_forward.c:743
send_hsr_supervision_frame+0x733/0xcf0 net/hsr/hsr_device.c:364
hsr_announce+0x1db/0x370 net/hsr/hsr_device.c:421
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x225/0x840 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:finish_task_switch+0x417/0xc60 kernel/sched/core.c:5361
Code: 04 00 00 41 c7 84 24 20 0e 00 00 00 00 00 00 0f 1f 44 00 00 49 83 c4 48 4c 89 e7 e8 43 7b 24 0a e8 ae bc 39 00 fb 4c 8b 65 c8 <49> 8d bc 24 f8 16 00 00 48 89 f8 48 c1 e8 03 42 0f b6 04 30 84 c0
RSP: 0018:ffffc9000377f7c0 EFLAGS: 00000202
RAX: 0000000000000161 RBX: ffff88801fc3bf20 RCX: 0000000080000001
RDX: 0000000000000006 RSI: ffffffff8dfe8e81 RDI: ffffffff8c2ac780
RBP: ffffc9000377f810 R08: ffffffff90331df7 R09: 1ffffffff20663be
R10: dffffc0000000000 R11: fffffbfff20663bf R12: ffff888039a5a540
R13: ffff88801fc3bee8 R14: dffffc0000000000 R15: 1ffff11003f877e4
context_switch kernel/sched/core.c:5513 [inline]
__schedule+0x17e1/0x56c0 kernel/sched/core.c:7234
preempt_schedule_common+0x82/0xd0 kernel/sched/core.c:7413
preempt_schedule_thunk+0x16/0x40 arch/x86/entry/thunk.S:12
smp_call_function_single+0x46e/0x5a0 kernel/smp.c:704
task_function_call kernel/events/core.c:124 [inline]
perf_install_in_context+0x5bd/0x900 kernel/events/core.c:3203
__do_sys_perf_event_open kernel/events/core.c:14239 [inline]
__se_sys_perf_event_open+0x1906/0x1d40 kernel/events/core.c:13881
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f111a19ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f111b0f9028 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00007f111a415fa0 RCX: 00007f111a19ce59
RDX: bfffffffffffffff RSI: 0000000000000000 RDI: 0000200000000180
RBP: 00007f111a232e6f R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000
R13: 00007f111a416038 R14: 00007f111a415fa0 R15: 00007ffe2b7b0cb8
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* Re: [PATCH net v2 1/1] net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
From: Simon Horman @ 2026-06-27 16:36 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, edumazet, kuba, pabeni, jiri, victor, security,
zdi-disclosures, stable, kernel test robot
In-Reply-To: <CAM0EoMntFA+fqs_BgT0E_KSsQHyf0W0u7OTngHHB7icrnUiC3A@mail.gmail.com>
On Fri, Jun 26, 2026 at 12:11:47PM -0400, Jamal Hadi Salim wrote:
> Hi Simon,
>
> On Fri, Jun 26, 2026 at 10:15 AM Simon Horman <horms@kernel.org> wrote:
> >
> > On Fri, Jun 26, 2026 at 06:16:43AM -0400, Jamal Hadi Salim wrote:
> > > "
> > >
> > > On Wed, Jun 24, 2026 at 6:40 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > > >
> > > > The teql master->slaves singly linked list is not protected against
> > > > multiple writes. It can be mod'ed concurently from teql_master_xmit(),
> > > > teql_dequeue(), teql_init() and teql_destroy() without holding any list
> > > > lock or RCU protection.
> > > >
> > > > zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
> > > > after an RCU grace period, but teql_master_xmit() running on another
> > > > CPU can still hold a stale pointer into the list, resulting in a
> > > > slab-use-after-free:
> > > >
> > > > BUG: KASAN: slab-use-after-free in teql_destroy+0x3ca/0x440 linux/net/sched/sch_teql.c:142
> > > > Read of size 8 at addr ffff88802923aa80 by task ip/10024
> > > >
> > > > The zdi-disclosures@trendmicro.com repro created concurrent AF_PACKET
> > > > senders on a teql device against a thread that repeatedly adds/deletes the
> > > > slave qdisc, together with a SLUB spray that reclaims the freed slot; the
> > > > resulting UAF is controllable enough to be turned into a read/write
> > > > primitive against the freed qdisc object.
> > > >
> > > > The fix?
> > > > Add a per-master slaves_lock spinlock that serializes all mutations of
> > > > master->slaves and the NEXT_SLAVE() links in teql_destroy() and
> > > > teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
> > > > around those updates.
> > > > Annotate master->slaves and the per-slave ->next pointer with __rcu and
> > > > use the appropriate RCU accessors everywhere they are touched:
> > > > rcu_assign_pointer() on the writer side (under slaves_lock),
> > > > rcu_dereference_protected() for the writer-side loads (also under
> > > > slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
> > > > rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
> > > > which run under RTNL.
> > > > Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
> > > > traversal in teql_master_xmit(), so that readers either observe a fully
> > > > linked list or are deferred until the in-flight mutation completes. The two
> > > > early-return paths in teql_master_xmit() are updated to release the RCU-bh
> > > > read-side critical section before returning, since leaving it held would
> > > > disable BH on that CPU for good.
> > > >
> > >
> > > sashiko-gemini's complaints:
> > > https://sashiko.dev/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com
> > > seem bogus to me (someone correct me if i am wrong). I am only going
> > > to address the first claim of "TOCTOU / "resurrection" race in
> > > teql_master_xmit()"
> > > teql_master_xmit() holds rcu_read_lock_bh() across the entire
> > > traversal. teql_destroy() freeing can only proceed once the qdisc's
> > > RCU grace period has elapsed - so where is this TOCTOU? Let's say this
> > > were true: both calls hold the slaves_lock.
> > > The other issues are of similar nature.
> >
> > Hi Jamal,
> >
> > I think the central question here is about the protection offered by RCU
> > in these code paths. And while I agree it protects the use of elements
> > of the list, I think the problem flagged relates to the management of
> > the list itself.
> >
> > The example AI gave me when I asked is like this:
> >
> > Assume a TEQL master has one slave, `q`.
> > The list is circular: `q->next == q`.
> >
> > 1. CPU A (Transmitting): Enters `teql_master_xmit()`.
> > It reads `master->sla ves` and gets a local pointer to `q`.
> >
> > 2. CPU B (Destroying): Calls `teql_destroy(q)`.
> > It takes the lock, unlinks `q`, and sets `master->slaves = NULL`.
> > The list is now logically empty.
> >
> > 3. CPU A: Finishes its work and prepares to rotate the list head
> > to the next slave.
> > It takes the lock.
> >
> > 4. CPU A (The "Use" / The Resurrection):
> > It executes: `rcu_assign_pointer(master->slaves, NEXT_SLAVE(q));`
> > Because `q` was circular, `NEXT_SLAVE(q)` is still `q`.
> >
> > 5. CPU A: Releases the lock.
> > **The global `master->slaves` is now `q` again.**
> >
> > 6. The System: The RCU grace period expires. CPU B finishes
> > `teql_destroy()` and the memory for `q` is freed.
> >
> > The global `master->slaves` pointer is now a **dangling pointer**
> > pointing to freed memory.
> >
>
>
> Yeah, thats the same earlier claim of TOCTOU (what sashiko-gemini
> claimed was "resurrecting the freed q")
> My view is rcu read lock blocks the subsequent call_rcu free - and
> destroy() and xmit() already serialize on slaves_lock.
The read of master->slaves is outside of the slaves_lock critical
section(s) in teql_master_xmit(). This is possibly the nub of this issue.
> I could be totaly wrong, but it's almost like sashiko-gemini thinks
> that the list-mutation lock _alone_ governs the object lifetime.
> The rcu read-side critical section prevents the UAF, not just the
> slaves_lock alone
> Only reason i added slaves_lock was to prevent corrupting the list
> state (whereas the RCU read lock prevents premature free).
>
> In step #4 above this thing somehow leaves out any mention of the rcu
> read lock entirely and places the free in step 6 as if it was
> independent of CPU A's critical section.
I see what you are saying regarding the free not occurring at step 4
because CPU A is in an RCU read-side critical section.
But once CPU A has assigned master->slaves as q (again) it exits
the RCU read-side critical section. Then the free of q can occur.
And master->slaves will point to memory that has been been freed.
So the access to q is safe when teql_master_xmit is invoked, due to RCU
protecting object lifetime. But it is unsafe when teql_master_xmit is
invoked again because by then master->slaves is a dangling pointer.
>
> I am not sure how to improve it.
>
> > > OTOH, sashiko-claude
> > > (https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com)
> > > does make some valid claims which are low value, so not sure a resend
> > > is worth it.
> > > For example in claim 1 it says "Should the changelog mention this
> > > teql_dequeue() site too?" Sure I can - but just because I provided
> > > extra information in the commit log, which I could have omitted, now I
> > > have to add more info? ;->
> >
> > FWIIW, I think there is a value in tightening up the commit message.
> > E.g. so it's accurate when we look at again in two years time.
> > But I also lean towards it not being necessary to post an update
> > only to address this.
> >
> >
> > > The second claim is "rcu_dereference_bh()
> > > should be rcu_dereference_protected() on writer side". Sparse didnt
> > > complain and i dont see this as breakage rather a consistency measure.
> >
> > I think it would be good to address in the long run. But as per my comment
> > immediately above, I also lean towards it not being necessary to post an
> > update only to address this.
>
> I can resend with these two taken care of - but i am skeptical of what
> sashiko-gemini is claiming (and i admit as a human the AI may see
> something i am totally missing).
>
> cheers,
> jamal
> >
> > > Unless I am missing something ..
> > >
> > > cheers,
> > > jamal
^ permalink raw reply
* [TEST] intel: low timeout
From: Jakub Kicinski @ 2026-06-27 16:54 UTC (permalink / raw)
To: Pielech, Adrian
Cc: Kitszel, Przemyslaw, netdev@vger.kernel.org, intel-wired-lan
Hi!
Some of the tests need more than 5min, could you increase the timeout
in the runner to 10 or 15min? Looks like it's hard-killing tests right
now after 2min:
https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-27--16-00/ice-E810-XXV4/xdp.py/stdout
which leaks config across tests:
https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-27--16-00/ice-E810-XXV4/irq.py/stdout
BTW the JSON reports the timed out tests as pass.
^ permalink raw reply
* [PATCH net v5 0/2] net: phy: sfp: fix mii_bus leak and revert RollBall bridge probe
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
v4 tried to fix the RollBall regression from 8fe125892f40 by deferring the
bridge probe to PHY discovery time. Maxime Chevallier and Aleksander
Bajkowski both tested that on genuine RollBall hardware and confirmed it
does not restore PHY detection (the module still is not ready when the
probe runs), and the Sashiko static review flagged the same path.
So this version drops the deferred-probe patch and instead reverts
8fe125892f40, restoring the pre-regression behaviour for genuine RollBall
modules. A proper fix for slow-initializing modules needs per-module init
timing (a longer module_t_wait / a per-module quirk) and genuine RollBall
hardware to validate; that is better owned as a follow-up by someone with
such a module.
Patch 1 is the independent mii_bus leak fix, unchanged, now carrying
Reviewed-by from Maxime and Larysa.
Patch 2 reverts 8fe125892f40.
v4: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Petr Wozniak (2):
net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in
mdio-i2c"
drivers/net/mdio/mdio-i2c.c | 59 +++++--------------------------------
drivers/net/phy/sfp.c | 15 +++-------
2 files changed, 11 insertions(+), 63 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH net v5 1/2] net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak,
Larysa Zaremba
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().
Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release")
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
---
drivers/net/phy/sfp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db9..c4d274ab651e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -963,6 +963,7 @@ static int sfp_i2c_mdiobus_create(struct sfp *sfp)
static void sfp_i2c_mdiobus_destroy(struct sfp *sfp)
{
mdiobus_unregister(sfp->i2c_mii);
+ mdiobus_free(sfp->i2c_mii);
sfp->i2c_mii = NULL;
}
--
2.51.0
^ permalink raw reply related
* [PATCH net v5 2/2] Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
This reverts commit 8fe125892f40 ("net: phy: sfp: probe for RollBall
I2C-to-MDIO bridge in mdio-i2c").
That commit added a RollBall bridge probe at MDIO bus creation time, in
i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on
modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT,
before genuine RollBall modules have finished their firmware/bridge
initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The
probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection
is then skipped for genuine RollBall modules that worked before the commit.
This was confirmed on hardware by Maxime Chevallier and Aleksander
Bajkowski: their RollBall modules no longer detect a PHY, and work again
on v7.0 (before the bridge probing was introduced). The Sashiko static
review flagged the same path.
Deferring the probe to PHY discovery time does not fix it either: at that
point a slow module may still be initializing, so the probe still returns
-ENODEV. A proper fix needs per-module init timing (a longer module_t_wait
or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms
after insertion), which requires genuine RollBall hardware to develop and
validate. Revert to restore the previous, working behaviour in the meantime.
The RTL8261BE retry-loop latency that the reverted commit addressed is
handled in our downstream tree, so reverting upstream is safe on our side.
Fixes: 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c")
Reported-by: Aleksander Bajkowski <olek2@wp.pl>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
drivers/net/mdio/mdio-i2c.c | 59 +++++--------------------------------
drivers/net/phy/sfp.c | 14 ++-------
2 files changed, 10 insertions(+), 63 deletions(-)
diff --git a/drivers/net/mdio/mdio-i2c.c b/drivers/net/mdio/mdio-i2c.c
index b88f63234b4e..ed20352a589a 100644
--- a/drivers/net/mdio/mdio-i2c.c
+++ b/drivers/net/mdio/mdio-i2c.c
@@ -419,50 +419,6 @@ static int i2c_mii_write_rollball(struct mii_bus *bus, int phy_id, int devad,
return 0;
}
-static int i2c_mii_probe_rollball(struct i2c_adapter *i2c)
-{
- u8 data_buf[] = { ROLLBALL_DATA_ADDR, 0x01, 0x00, 0x00 };
- u8 cmd_buf[] = { ROLLBALL_CMD_ADDR, ROLLBALL_CMD_READ };
- u8 cmd_addr = ROLLBALL_CMD_ADDR;
- struct i2c_msg msgs[2];
- u8 result;
- int ret;
- int i;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = sizeof(data_buf);
- msgs[0].buf = data_buf;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = 0;
- msgs[1].len = sizeof(cmd_buf);
- msgs[1].buf = cmd_buf;
-
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = 1;
- msgs[0].buf = &cmd_addr;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = I2C_M_RD;
- msgs[1].len = 1;
- msgs[1].buf = &result;
-
- for (i = 0; i < 10; i++) {
- msleep(20);
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
- if (result == ROLLBALL_CMD_DONE)
- return 0;
- }
-
- return -ENODEV;
-}
-
static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
{
struct i2c_msg msg;
@@ -482,11 +438,11 @@ static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
ret = i2c_transfer(i2c, &msg, 1);
if (ret < 0)
- return -ENODEV;
- if (ret != 1)
+ return ret;
+ else if (ret != 1)
return -EIO;
-
- return i2c_mii_probe_rollball(i2c);
+ else
+ return 0;
}
static bool mdio_i2c_check_functionality(struct i2c_adapter *i2c,
@@ -531,10 +487,9 @@ struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
case MDIO_I2C_ROLLBALL:
ret = i2c_mii_init_rollball(i2c);
if (ret < 0) {
- if (ret != -ENODEV)
- dev_err(parent,
- "Cannot initialize RollBall MDIO I2C protocol: %d\n",
- ret);
+ dev_err(parent,
+ "Cannot initialize RollBall MDIO I2C protocol: %d\n",
+ ret);
mdiobus_free(mii);
return ERR_PTR(ret);
}
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index c4d274ab651e..f520206734da 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -597,7 +597,6 @@ static const struct sfp_quirk sfp_quirks[] = {
// OEM SFP-GE-T is a 1000Base-T module with broken TX_FAULT indicator
SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
- SFP_QUIRK_F("OEM", "SFP-10G-T-I", sfp_fixup_rollball),
SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
SFP_QUIRK_S("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
SFP_QUIRK_S("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),
@@ -2174,17 +2173,10 @@ static void sfp_sm_fault(struct sfp *sfp, unsigned int next_state, bool warn)
static int sfp_sm_add_mdio_bus(struct sfp *sfp)
{
- int ret;
-
- if (sfp->mdio_protocol == MDIO_I2C_NONE)
- return 0;
+ if (sfp->mdio_protocol != MDIO_I2C_NONE)
+ return sfp_i2c_mdiobus_create(sfp);
- ret = sfp_i2c_mdiobus_create(sfp);
- if (ret == -ENODEV) {
- sfp->mdio_protocol = MDIO_I2C_NONE;
- return 0;
- }
- return ret;
+ return 0;
}
/* Probe a SFP for a PHY device if the module supports copper - the PHY
--
2.51.0
^ permalink raw reply related
* Re: [PATCH bpf v2 0/4] bpf, sockmap: Fix sockmap leaking UDP socks
From: sun jian @ 2026-06-27 17:34 UTC (permalink / raw)
To: Michal Luczaj
Cc: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
John Fastabend, Jakub Sitnicki, Jiayuan Chen, David S. Miller,
Jakub Kicinski, Simon Horman, Alexei Starovoitov, Cong Wang,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Shuah Khan, netdev,
bpf, linux-kernel, linux-kselftest
In-Reply-To: <20260626-sockmap-lookup-udp-leak-v2-0-7e7e201c951a@rbox.co>
On Sat, Jun 27, 2026 at 4:37 AM Michal Luczaj <mhal@rbox.co> wrote:
>
> Fix for UDP sockets getting leaked during sockmap lookup/release.
> Accompanied by selftests updates.
>
> Signed-off-by: Michal Luczaj <mhal@rbox.co>
> ---
> Changes in v2:
> - selftest: drop the original, adapt old tests
> - fix: change approach to rejecting unbound UDP [Kuniyuki]
> - Link to v1: https://patch.msgid.link/20260623-sockmap-lookup-udp-leak-v1-0-05804f9308e4@rbox.co
>
> ---
> Michal Luczaj (4):
> bpf, sockmap: Reject unhashed UDP sockets on sockmap update
> selftests/bpf: Ensure UDP sockets are bound
> selftests/bpf: Adapt sockmap update error handling
> selftests/bpf: Fail unbound UDP on sockmap update
>
> net/core/sock_map.c | 2 ++
> tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 6 +++---
> tools/testing/selftests/bpf/prog_tests/sockmap_listen.c | 17 +++++++++--------
> tools/testing/selftests/bpf/test_maps.c | 6 +++---
> 4 files changed, 17 insertions(+), 14 deletions(-)
> ---
> base-commit: 26490a375cb9be9bac96b5171610fd85ca6c2305
> change-id: 20260617-sockmap-lookup-udp-leak-bc4e5c5481d7
>
> Best regards,
> --
> Michal Luczaj <mhal@rbox.co>
>
>
Hi Michal,
I tested this series on bpf.git base commit:
26490a375cb9be9bac96b5171610fd85ca6c2305
The test environment was virtme-ng x86_64.
Before, with only patches 2/4-4/4 applied:
sockmap_basic: PASS
sockmap_listen: FAIL as expected
- UDP test_insert_opened failed on sockmap/sockhash,
both IPv4 and IPv6
test_maps: FAIL as expected
- failed at the new unbound SOCK_DGRAM update check
After applying the full series:
sockmap_basic: PASS
sockmap_listen: PASS
test_maps: no longer failed at the unbound
SOCK_DGRAM update check
test_maps still later reported:
Failed sockmap unexpected timeout
However, I can reproduce the same timeout in three consecutive
runs on the unmodified base commit, so this looks pre-existing or
environmental in my virtme-ng setup rather than a regression from
this series.
I am not adding a Tested-by tag for now because test_maps does not
fully pass in my setup. The targeted before/after behavior behaved as
expected.
Thanks,
Sun Jian
^ permalink raw reply
* Re: [PATCH net v2] nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
From: David Heidelberg @ 2026-06-27 18:15 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260624224455.999374-1-sam@bynar.io>
On Wed, 24 Jun 2026 23:44:55 +0100, Samuel Page wrote:
> nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
Applied, thanks!
[1/1] nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
commit: 27d431711a3a6e23e7f961ec2934de20e2ed7cac
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH net] nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
From: David Heidelberg @ 2026-06-27 18:34 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260622145243.3167276-1-sam@bynar.io>
On Mon, 22 Jun 2026 16:52:43 +0200, Samuel Page wrote:
> nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
Applied, thanks!
[1/1] nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
commit: e87faad807329d1348595dbcea3444acd7bb0ca6
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH net v2] nfc: nci: fix uninit-value in the RF discover/activated NTF handlers
From: David Heidelberg @ 2026-06-27 18:41 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260626090301.2139500-1-sam@bynar.io>
On 26/06/2026 11:03, Samuel Page wrote:
> nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each
> parse a notification into an on-stack struct (nci_rf_discover_ntf /
> nci_rf_intf_activated_ntf) that is not initialised. The RF
> technology-specific parameters are only extracted when
> rf_tech_specific_params_len is non-zero, so a notification that reports a
> zero length leaves the rf_tech_specific_params union uninitialised - and
> both handlers then pass it to nci_add_new_protocol(), which reads it:
>
> - discover: nci_add_new_target() -> nci_add_new_protocol();
> - activated: nci_target_auto_activated() -> nci_add_new_protocol().
>
> nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch
> condition and a memcpy() length and copies nfcid1/sens_res/sel_res into
> ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET.
>
> BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0
> nci_add_new_protocol+0x624/0x6c0
> nci_ntf_packet+0x25b2/0x3c30
> nci_rx_work+0x318/0x5d0
> process_scheduled_works+0x84b/0x17a0
> worker_thread+0xc10/0x11b0
> kthread+0x376/0x500
> Local variable ntf.i created at:
> nci_ntf_packet+0xbc2/0x3c30
>
> Zero-initialise both on-stack notifications so the union reads back as
> zero when no technology-specific parameters are present.
>
> Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support")
> Fixes: e8c0dacd9836 ("NFC: Update names and structs to NCI spec 1.0 d18")
> Link: https://lore.kernel.org/netdev/20260623172109.1105965-2-horms@kernel.org/
> Cc: stable@vger.kernel.org
> Assisted-by: Bynario AI
Hello Samuel,
the fix look good, may I ask you to follow the Assisted-by syntax as requested
in [1]?
Thank you
David
[1] https://docs.kernel.org/process/coding-assistants.html
> Signed-off-by: Samuel Page <sam@bynar.io>
> ---
> v2: Drop the inaccurate activation_params / NFC_ATTR_TARGET_ATS scenario
> from the commit message. No code change; the ntf = {} fix is unchanged.
>
> net/nfc/nci/ntf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
[...]
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Jiri Slaby @ 2026-06-27 19:04 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
federico.vaga, carlos.bilbao, avadhut.naik, alexs, si.yanteng,
dzm91, 2023002089, tsbogend, dsahern, jani.nikula, mchehab+huawei,
gregkh, tytso, herbert, ebiggers, johannes.berg, geert, pablo,
tglx, mashiro.chen, mingo, dqfext, jreuter, sdf, pkshih,
enelsonmoore, mkl, toke, kees, crossd, jlayton, wangliang74,
aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <20260421021824.1293976-1-kuba@kernel.org>
On 21. 04. 26, 4:18, Jakub Kicinski wrote:
> Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation
> and all associated hamradio device drivers from the kernel tree.
> This set of protocols has long been a huge bug/syzbot magnet,
> and since nobody stepped up to help us deal with the influx
> of the AI-generated bug reports we need to move it out of tree
> to protect our sanity.
>
> The code is moved to an out-of-tree repo:
> https://github.com/linux-netdev/mod-orphan
> if it's cleaned up and reworked there we can accept it back.
>
> Minimal stub headers are kept for include/net/ax25.h (AX25_P_IP,
> AX25_ADDR_LEN, ax25_address) and include/net/rose.h (ROSE_ADDR_LEN)
> so that the conditional integration code in arp.c and tun.c continues
> to compile and work when the out-of-tree modules are loaded.
...
> delete mode 100644 include/uapi/linux/scc.h
Unfortunately, this broke builds of LLVM -- compiler-rt in particular
(and GCC builds allegedly too). They dropped the include and its use
[1], but IMO we should keep the uapi header with those two structs
(scc_modem + scc_stat) for some time.
[1]
https://github.com/llvm/llvm-project/commit/3dc4fd6dd41100f051a63642f449b16324389c96
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH net] usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
From: Xiang Mei @ 2026-06-27 20:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
Cc: linux-usb, linux-kernel, Weiming Shi, Xiang Mei
genelink_rx_fixup() splits an aggregated RX frame into its individual
packets, using a per-packet length taken from device-supplied data. That
length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared
against how many bytes were actually received.
A malicious GeneLink (GL620A) device can therefore send a short URB whose
header claims packet_count > 1 and a first packet of up to 1514 bytes.
skb_put_data(gl_skb, packet->packet_data, size);
then copies past the end of the receive buffer and hands the adjacent slab
contents up the network stack, an out-of-bounds read that leaks kernel heap.
No privilege is required: the path runs in the usbnet RX softirq as soon as
the interface is up.
BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)
Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14
Call Trace:
...
__asan_memcpy (mm/kasan/shadow.c:105)
genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)
usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3405)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
run_ksoftirqd (kernel/softirq.c:1076)
...
skb_pull() already verifies that the requested length fits the buffer and
returns NULL otherwise. Move it ahead of the copy and check its result, so
a packet that overruns the received data is rejected before it is read.
Well-formed frames, whose packets are fully present, are unaffected.
Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
drivers/net/usb/gl620a.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index 0bfa37c14059..09afd137b64e 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -104,6 +104,9 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
return 0;
}
+ if (!skb_pull(skb, size + 4))
+ return 0;
+
// allocate the skb for the individual packet
gl_skb = alloc_skb(size, GFP_ATOMIC);
if (gl_skb) {
@@ -116,9 +119,6 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
// advance to the next packet
packet = (struct gl_packet *)&packet->packet_data[size];
count--;
-
- // shift the data pointer to the next gl_packet
- skb_pull(skb, size + 4);
}
// skip the packet length field 4 bytes
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v2 1/1] net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
From: Jamal Hadi Salim @ 2026-06-27 21:03 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, davem, edumazet, kuba, pabeni, jiri, victor, security,
zdi-disclosures, stable, kernel test robot
In-Reply-To: <20260627163602.GG1310988@horms.kernel.org>
On Sat, Jun 27, 2026 at 12:36 PM Simon Horman <horms@kernel.org> wrote:
>
> On Fri, Jun 26, 2026 at 12:11:47PM -0400, Jamal Hadi Salim wrote:
> > Hi Simon,
> >
> > On Fri, Jun 26, 2026 at 10:15 AM Simon Horman <horms@kernel.org> wrote:
> > >
> > > On Fri, Jun 26, 2026 at 06:16:43AM -0400, Jamal Hadi Salim wrote:
> > > > "
> > > >
> > > > On Wed, Jun 24, 2026 at 6:40 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > > > >
> > > > > The teql master->slaves singly linked list is not protected against
> > > > > multiple writes. It can be mod'ed concurently from teql_master_xmit(),
> > > > > teql_dequeue(), teql_init() and teql_destroy() without holding any list
> > > > > lock or RCU protection.
> > > > >
> > > > > zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
> > > > > after an RCU grace period, but teql_master_xmit() running on another
> > > > > CPU can still hold a stale pointer into the list, resulting in a
> > > > > slab-use-after-free:
> > > > >
> > > > > BUG: KASAN: slab-use-after-free in teql_destroy+0x3ca/0x440 linux/net/sched/sch_teql.c:142
> > > > > Read of size 8 at addr ffff88802923aa80 by task ip/10024
> > > > >
> > > > > The zdi-disclosures@trendmicro.com repro created concurrent AF_PACKET
> > > > > senders on a teql device against a thread that repeatedly adds/deletes the
> > > > > slave qdisc, together with a SLUB spray that reclaims the freed slot; the
> > > > > resulting UAF is controllable enough to be turned into a read/write
> > > > > primitive against the freed qdisc object.
> > > > >
> > > > > The fix?
> > > > > Add a per-master slaves_lock spinlock that serializes all mutations of
> > > > > master->slaves and the NEXT_SLAVE() links in teql_destroy() and
> > > > > teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
> > > > > around those updates.
> > > > > Annotate master->slaves and the per-slave ->next pointer with __rcu and
> > > > > use the appropriate RCU accessors everywhere they are touched:
> > > > > rcu_assign_pointer() on the writer side (under slaves_lock),
> > > > > rcu_dereference_protected() for the writer-side loads (also under
> > > > > slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
> > > > > rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
> > > > > which run under RTNL.
> > > > > Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
> > > > > traversal in teql_master_xmit(), so that readers either observe a fully
> > > > > linked list or are deferred until the in-flight mutation completes. The two
> > > > > early-return paths in teql_master_xmit() are updated to release the RCU-bh
> > > > > read-side critical section before returning, since leaving it held would
> > > > > disable BH on that CPU for good.
> > > > >
> > > >
> > > > sashiko-gemini's complaints:
> > > > https://sashiko.dev/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com
> > > > seem bogus to me (someone correct me if i am wrong). I am only going
> > > > to address the first claim of "TOCTOU / "resurrection" race in
> > > > teql_master_xmit()"
> > > > teql_master_xmit() holds rcu_read_lock_bh() across the entire
> > > > traversal. teql_destroy() freeing can only proceed once the qdisc's
> > > > RCU grace period has elapsed - so where is this TOCTOU? Let's say this
> > > > were true: both calls hold the slaves_lock.
> > > > The other issues are of similar nature.
> > >
> > > Hi Jamal,
> > >
> > > I think the central question here is about the protection offered by RCU
> > > in these code paths. And while I agree it protects the use of elements
> > > of the list, I think the problem flagged relates to the management of
> > > the list itself.
> > >
> > > The example AI gave me when I asked is like this:
> > >
> > > Assume a TEQL master has one slave, `q`.
> > > The list is circular: `q->next == q`.
> > >
> > > 1. CPU A (Transmitting): Enters `teql_master_xmit()`.
> > > It reads `master->sla ves` and gets a local pointer to `q`.
> > >
> > > 2. CPU B (Destroying): Calls `teql_destroy(q)`.
> > > It takes the lock, unlinks `q`, and sets `master->slaves = NULL`.
> > > The list is now logically empty.
> > >
> > > 3. CPU A: Finishes its work and prepares to rotate the list head
> > > to the next slave.
> > > It takes the lock.
> > >
> > > 4. CPU A (The "Use" / The Resurrection):
> > > It executes: `rcu_assign_pointer(master->slaves, NEXT_SLAVE(q));`
> > > Because `q` was circular, `NEXT_SLAVE(q)` is still `q`.
> > >
> > > 5. CPU A: Releases the lock.
> > > **The global `master->slaves` is now `q` again.**
> > >
> > > 6. The System: The RCU grace period expires. CPU B finishes
> > > `teql_destroy()` and the memory for `q` is freed.
> > >
> > > The global `master->slaves` pointer is now a **dangling pointer**
> > > pointing to freed memory.
> > >
> >
> >
> > Yeah, thats the same earlier claim of TOCTOU (what sashiko-gemini
> > claimed was "resurrecting the freed q")
> > My view is rcu read lock blocks the subsequent call_rcu free - and
> > destroy() and xmit() already serialize on slaves_lock.
>
> The read of master->slaves is outside of the slaves_lock critical
> section(s) in teql_master_xmit(). This is possibly the nub of this issue.
>
Yes, i think this could cause an issue on a second run of xmit() ;->
Let me ponder on it. I will probably have something tommorow..
cheers,
jamal
> > I could be totaly wrong, but it's almost like sashiko-gemini thinks
> > that the list-mutation lock _alone_ governs the object lifetime.
> > The rcu read-side critical section prevents the UAF, not just the
> > slaves_lock alone
> > Only reason i added slaves_lock was to prevent corrupting the list
> > state (whereas the RCU read lock prevents premature free).
> >
> > In step #4 above this thing somehow leaves out any mention of the rcu
> > read lock entirely and places the free in step 6 as if it was
> > independent of CPU A's critical section.
>
> I see what you are saying regarding the free not occurring at step 4
> because CPU A is in an RCU read-side critical section.
>
> But once CPU A has assigned master->slaves as q (again) it exits
> the RCU read-side critical section. Then the free of q can occur.
> And master->slaves will point to memory that has been been freed.
>
> So the access to q is safe when teql_master_xmit is invoked, due to RCU
> protecting object lifetime. But it is unsafe when teql_master_xmit is
> invoked again because by then master->slaves is a dangling pointer.
>
> >
> > I am not sure how to improve it.
> >
> > > > OTOH, sashiko-claude
> > > > (https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com)
> > > > does make some valid claims which are low value, so not sure a resend
> > > > is worth it.
> > > > For example in claim 1 it says "Should the changelog mention this
> > > > teql_dequeue() site too?" Sure I can - but just because I provided
> > > > extra information in the commit log, which I could have omitted, now I
> > > > have to add more info? ;->
> > >
> > > FWIIW, I think there is a value in tightening up the commit message.
> > > E.g. so it's accurate when we look at again in two years time.
> > > But I also lean towards it not being necessary to post an update
> > > only to address this.
> > >
> > >
> > > > The second claim is "rcu_dereference_bh()
> > > > should be rcu_dereference_protected() on writer side". Sparse didnt
> > > > complain and i dont see this as breakage rather a consistency measure.
> > >
> > > I think it would be good to address in the long run. But as per my comment
> > > immediately above, I also lean towards it not being necessary to post an
> > > update only to address this.
> >
> > I can resend with these two taken care of - but i am skeptical of what
> > sashiko-gemini is claiming (and i admit as a human the AI may see
> > something i am totally missing).
> >
> > cheers,
> > jamal
> > >
> > > > Unless I am missing something ..
> > > >
> > > > cheers,
> > > > jamal
^ permalink raw reply
* Re: [PATCH net-next v14 0/9] tls: Add TLS 1.3 hardware offload support
From: Nils Juenemann @ 2026-06-27 21:06 UTC (permalink / raw)
To: rjethwani
Cc: borisp, davem, edumazet, john.fastabend, kuba, leon, mbloch,
netdev, pabeni, saeedm, sd, tariqt
In-Reply-To: <20260515212715.3151307-1-rjethwani@purestorage.com>
Hi Rishikesh, all,
thanks for picking up the sendfile/EOF fix in tls_device_splice_eof().
Separate issue we hit while testing, looks pre-existing in mlx5e
rather than v14: a NULL deref on the RX offload path. Trigger is
ethtool -L <dev> combined 32 (down from 64) under HW-kTLS load,
then a TLS_RX offload setup:
BUG: unable to handle page fault for address: 00000000000031c0
RIP: mlx5e_ktls_add_rx+0x268 [mlx5_core]
Call Trace:
mlx5e_ktls_add
tls_device_dev_add_rx
tls_set_device_offload_rx
tls_setsockopt
sk_rx_queue_get(sk) returns a stale rxq (62 here) after the
reduction; mlx5e_ktls_sk_get_rxq() only guards rxq == -1, so
mlx5e_ktls_add_rx() dereferences priv->channels.c[62], which
appears to be NULL. The resync paths index
priv->channels.c[priv_rx->rxq] the same way. This path is not
TLS 1.3 specific.
I do not have a proposed fix yet. Happy to share the full
decoded oops / additional kdump details or test patches.
Thanks again,
Nils Juenemann
^ permalink raw reply
* Re: [PATCH] netfilter: x_tables: replace strlcat() with snprintf()
From: David Laight @ 2026-06-27 21:16 UTC (permalink / raw)
To: Ian Bridges
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening
In-Reply-To: <aj78X4Cjqcpbb8Co@dev>
On Fri, 26 Jun 2026 17:25:35 -0500
Ian Bridges <icb@fastmail.org> wrote:
> In preparation for removing the deprecated strlcat() API[1], replace the
> strscpy()/strlcat() pairs in xt_proto_init() and xt_proto_fini() with
> snprintf(), which builds each /proc file name in a single call.
>
> Each name is "<prefix><suffix>", where <prefix> is the address-family
> string xt_prefix[af] and <suffix> is one of the FORMAT_TABLES,
> FORMAT_MATCHES or FORMAT_TARGETS literals. snprintf() with a "%s%s"
> format produces the same NUL-terminated, length-bounded string as the
> strscpy()/strlcat() chain it replaces, so the proc entry names are
> unchanged.
>
> Link: https://github.com/KSPP/linux/issues/370 [1]
> Signed-off-by: Ian Bridges <icb@fastmail.org>
> ---
> net/netfilter/x_tables.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index 4e6708c23922..56f4546be336 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -2033,8 +2033,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> root_uid = make_kuid(net->user_ns, 0);
> root_gid = make_kgid(net->user_ns, 0);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
If you are going to use snprintf either paste the strings together:
snprintf(buf, sizeof(buf), "%s" FORMAT_TABLES, xt_prefix[af]);
or prepend the "%s" onto the #define of FORMAT_TABLES itself:
snprintf(buf, sizeof(buf), FORMAT_TABLES, xt_prefix[af]);
FORMAT_TABLES should also be FORMAT_NAMES.
-- David
> proc = proc_create_net_data(buf, 0440, net->proc_net, &xt_table_seq_ops,
> sizeof(struct seq_net_private),
> (void *)(unsigned long)af);
> @@ -2043,8 +2042,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> if (uid_valid(root_uid) && gid_valid(root_gid))
> proc_set_user(proc, root_uid, root_gid);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> proc = proc_create_seq_private(buf, 0440, net->proc_net,
> &xt_match_seq_ops, sizeof(struct nf_mttg_trav),
> (void *)(unsigned long)af);
> @@ -2053,8 +2051,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> if (uid_valid(root_uid) && gid_valid(root_gid))
> proc_set_user(proc, root_uid, root_gid);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TARGETS, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TARGETS);
> proc = proc_create_seq_private(buf, 0440, net->proc_net,
> &xt_target_seq_ops, sizeof(struct nf_mttg_trav),
> (void *)(unsigned long)af);
> @@ -2068,13 +2065,11 @@ int xt_proto_init(struct net *net, u_int8_t af)
>
> #ifdef CONFIG_PROC_FS
> out_remove_matches:
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> remove_proc_entry(buf, net->proc_net);
>
> out_remove_tables:
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
> remove_proc_entry(buf, net->proc_net);
> out:
> return -1;
> @@ -2087,16 +2082,13 @@ void xt_proto_fini(struct net *net, u_int8_t af)
> #ifdef CONFIG_PROC_FS
> char buf[XT_FUNCTION_MAXNAMELEN];
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
> remove_proc_entry(buf, net->proc_net);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TARGETS, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TARGETS);
> remove_proc_entry(buf, net->proc_net);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> remove_proc_entry(buf, net->proc_net);
> #endif /*CONFIG_PROC_FS*/
> }
^ permalink raw reply
* Re: [RFC PATCH net-next] netpoll: hold RCU while walking napi_list
From: Jakub Kicinski @ 2026-06-27 21:21 UTC (permalink / raw)
To: Runyu Xiao
Cc: davem, edumazet, pabeni, horms, leitao, sashal, bigeasy, netdev,
linux-kernel, jianhao.xu
In-Reply-To: <20260627101228.1191586-1-runyu.xiao@seu.edu.cn>
On Sat, 27 Jun 2026 18:12:28 +0800 Runyu Xiao wrote:
> CONFIG_PROVE_RCU_LIST reports the poll_napi() traversal when the helper
> is exercised directly from netpoll_poll_dev(). The current source has
> important lifetime defenses around NAPI deletion and netpoll device
> close, so this is not presented as a proven use-after-free. The issue is
> that the RCU-list reader contract is implicit at the helper boundary.
Please provide the stack trace from the report, rather than just saying
that you can trigger it.
--
pw-bot: rfc
^ permalink raw reply
* Re: [PATCH] netdevsim: remove debugfs files before freeing net_device
From: Jakub Kicinski @ 2026-06-27 21:21 UTC (permalink / raw)
To: syzbot
Cc: syzkaller-bugs, Andrew Lunn, David S. Miller, Eric Dumazet,
netdev, Paolo Abeni, linux-kernel, syzbot
In-Reply-To: <f15205c4-30e1-454f-97e6-92067a74f98f@mail.kernel.org>
On Sat, 27 Jun 2026 11:20:11 +0000 (UTC) syzbot wrote:
> A KASAN slab-use-after-free was detected in debugfs_u32_get() when reading
> a debugfs file associated with a netdevsim port.
Please read the replies to previous submissions:
https://lore.kernel.org/all/20260626184856.4b7f5228@kernel.org/
--
pw-bot: cr
^ 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