* Re: [PATCH v2 0/3] bpf: fix sock_ops rtt_min OOB read and related guard issues
From: patchwork-bot+netdevbpf @ 2026-04-12 19:40 UTC (permalink / raw)
To: Werner Kasselman
Cc: martin.lau, ast, daniel, andrii, john.fastabend, brakmo, eddyz87,
song, yonghong.song, kpsingh, sdf, haoluo, jolsa, davem, edumazet,
kuba, pabeni, horms, bpf, netdev, linux-kernel
In-Reply-To: <20260412030306.3469543-1-werner@verivus.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 12 Apr 2026 03:03:08 +0000 you wrote:
> Patch 3 fixes an out-of-bounds read in sock_ops_convert_ctx_access()
> for the rtt_min context field. It is the only tcp_sock-backed field
> that bypasses the is_locked_tcp_sock guard, so on request_sock-backed
> sock_ops callbacks the converted BPF load reads past the end of a
> tcp_request_sock.
>
> Patches 1 and 2 are groundwork. Patch 1 fixes a pre-existing info
> leak in SOCK_OPS_GET_FIELD() and SOCK_OPS_GET_SK() where dst_reg is
> left holding the context pointer on the guard-failure branch when
> dst_reg == src_reg, instead of being zeroed. Patch 2 extracts
> SOCK_OPS_LOAD_TCP_SOCK_FIELD() from SOCK_OPS_GET_FIELD() so the
> rtt_min sub-field access in patch 3 can reuse it.
>
> [...]
Here is the summary with links:
- [v2,1/3] bpf: zero dst_reg on sock_ops field guard failure when dst == src
https://git.kernel.org/netdev/net/c/10f86a2a5c91
- [v2,2/3] bpf: extract SOCK_OPS_LOAD_TCP_SOCK_FIELD from SOCK_OPS_GET_FIELD
(no matching commit)
- [v2,3/3] bpf: guard sock_ops rtt_min against non-locked tcp_sock
(no matching commit)
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 0/3] net: phy: add support for disabling autonomous EEE
From: patchwork-bot+netdevbpf @ 2026-04-12 19:40 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
florian.fainelli, bcm-kernel-feedback-list, netdev, linux-kernel
In-Reply-To: <20260406-devel-autonomous-eee-v1-0-b335e7143711@tipi-net.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 06 Apr 2026 09:13:06 +0200 you wrote:
> Some PHYs implement autonomous EEE where the PHY manages EEE
> independently, preventing the MAC from controlling LPI signaling.
> This conflicts with MACs that implement their own LPI control.
>
> This series adds a .disable_autonomous_eee callback to struct phy_driver
> and calls it from phy_support_eee(). When a MAC indicates it supports
> EEE, the PHY's autonomous EEE is automatically disabled. The setting is
> persisted across suspend/resume by re-applying it in phy_init_hw() after
> soft reset, following the same pattern suggested by Russell King for PHY
> tunables [1].
>
> [...]
Here is the summary with links:
- [net-next,1/3] net: phy: add support for disabling PHY-autonomous EEE
https://git.kernel.org/netdev/net-next/c/7ef629b45801
- [net-next,2/3] net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx
https://git.kernel.org/netdev/net-next/c/bcb3e89fc0ec
- [net-next,3/3] net: phy: realtek: convert RTL8211F to .disable_autonomous_eee
https://git.kernel.org/netdev/net-next/c/bb14e3b63c63
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] gre: Count GRE packet drops
From: patchwork-bot+netdevbpf @ 2026-04-12 19:40 UTC (permalink / raw)
To: Gal Pressman
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, netdev, dsahern,
horms, dtatulea, noren
In-Reply-To: <20260409090945.1542440-1-gal@nvidia.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 12:09:45 +0300 you wrote:
> GRE is silently dropping packets without updating statistics.
>
> In case of drop, increment rx_dropped counter to provide visibility into
> packet loss. For the case where no GRE protocol handler is registered,
> use rx_nohandler.
>
> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
> Reviewed-by: Nimrod Oren <noren@nvidia.com>
> Signed-off-by: Gal Pressman <gal@nvidia.com>
>
> [...]
Here is the summary with links:
- [net-next] gre: Count GRE packet drops
https://git.kernel.org/netdev/net-next/c/8632175ccb0c
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 bpf-next v2 2/3] bpf: Use kmalloc_nolock() universally in local storage
From: Slava Imameev @ 2026-04-12 19:40 UTC (permalink / raw)
To: alexei.starovoitov
Cc: ameryhung, andrii, ast, bot+bpf-ci, bpf, clm, daniel, eddyz87,
ihor.solodrai, kernel-team, martin.lau, memxor, netdev,
yonghong.song
In-Reply-To: <CAADnVQKeFF--bgnZZSU12UY0muuwYA=7EdzLyOi837oZs+bXTA@mail.gmail.com>
On Fri, 10 Apr 2026 21:39:00 -0700 Alexei Starovoitov wrote:
> >
> >
> > This allows value sizes up to ~65KB. Before this patch, socket and
> > inode storage used bpf_map_kzalloc() (backed by regular kmalloc)
> > which could handle those large sizes. After this patch, any
> > elem_size above KMALLOC_MAX_CACHE_SIZE will silently fail: the map
> > creation succeeds via bpf_local_storage_map_alloc_check() but every
> > element allocation returns NULL.
> >
> > Should BPF_LOCAL_STORAGE_MAX_VALUE_SIZE be updated to use
> > KMALLOC_MAX_CACHE_SIZE instead of KMALLOC_MAX_SIZE now that all
> > storage types go through kmalloc_nolock()?
> >
> > Slava Imameev raised the same concern for task storage in
> > https://lore.kernel.org/bpf/20260410014341.47043-1-slava.imameev@crowdstrike.com/
>
> Right. Let's update it, but I don't think it's a regression.
> On a loaded system kmalloc_large() rarely succeeds for order 2+.
> That's why kmalloc_nolock() doesn't attempt to bridge that gap.
> One or two contiguous physical pages is the best one can expect.
> In early bpf days we picked KMALLOC_MAX_SIZE assuming that
> it's a realistic max for kmalloc().
> It turned out to be wishful thinking.
> kmalloc_large concept should really be removed.
> It deceives users into thinking that it's usable.
Do you think it would be viable to extend task storage to
support larger allocations, to restore support for 64KB or maybe
less value like 32 KB, using vmalloc or bpf_mem_cache_alloc,
with the obvious restrictions that vmalloc imposes? Perhaps we
could use bpf_mem_cache_alloc as the primary mechanism with
vmalloc as a fallback when the caller context permits?
We've found task storage allocations larger than 8KB quite
valuable for scenarios involving processing multiple file paths.
Currently, without large task storage support, we're forced to
preallocate maps with 12KB+ values and significantly
over-provision the number of entries to reduce the probability
of free entry depletion. This approach places unnecessary burden
on the memory subsystem since much of this pre-allocated memory
remains unused.
Even if task storage allocation fails due to lack of contiguous
physical memory and vmalloc is not possible, there's an option to
maintain an emergency preallocated map of much smaller size
compared to when this map serves as the primary mechanism.
With larger task storage allocations, we've implemented a simple
memory allocator that operates over task storage. For example, a
16KB task storage can accommodate multiple allocations, one big
and couple of small, which has substantially reduced our memory
footprint compared to the current map-based approach. We've also
experimented successfully with 32KB arenas for workloads
requiring even larger working sets.
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Jakub Kicinski @ 2026-04-12 19:45 UTC (permalink / raw)
To: luka.gejak; +Cc: davem, edumazet, pabeni, netdev, fmaurer, horms
In-Reply-To: <20260407162502.19462-2-luka.gejak@linux.dev>
On Tue, 7 Apr 2026 18:25:01 +0200 luka.gejak@linux.dev wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> Supervision frames are only valid if terminated with a zero-length EOT
> TLV. The current check fails to reject non-EOT entries as the terminal
> TLV, potentially allowing malformed supervision traffic.
>
> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
> with a length of zero, and properly linearizing the TLV header before
> access.
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index 0aca859c88cb..eb89cc44eac0 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -82,35 +82,33 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
> hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct hsr_sup_payload))
> return false;
>
> - /* Get next tlv */
> + /* Get next TLV */
The capitalization of the comments makes the real changes in this patch
harder to spot and follow. Please don't tweak the comments unless you're
really changing / improving them.
> total_length += hsr_sup_tag->tlv.HSR_TLV_length;
> - if (!pskb_may_pull(skb, total_length))
> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
> return false;
> skb_pull(skb, total_length);
> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
> skb_push(skb, total_length);
>
> - /* if this is a redbox supervision frame we need to verify
> - * that more data is available
> - */
> + /* If this is a RedBox supervision frame, verify additional data */
> if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
> - /* tlv length must be a length of a mac address */
> + /* TLV length must be the size of a MAC address */
> if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct hsr_sup_payload))
> return false;
>
> - /* make sure another tlv follows */
> + /* Make sure another TLV follows */
> total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv->HSR_TLV_length;
> - if (!pskb_may_pull(skb, total_length))
> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
> return false;
>
> - /* get next tlv */
> + /* Get next TLV */
> skb_pull(skb, total_length);
> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
> skb_push(skb, total_length);
> }
>
> - /* end of tlvs must follow at the end */
> - if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
> + /* Supervision frame must end with EOT TLV */
> + if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
> hsr_sup_tlv->HSR_TLV_length != 0)
> return false;
Aren't there more optional TLVs that we don't support?
You mentioned making sure that the final TLV is a zero-length EOT
but this check is far stricter.
Should we replace this check with a loop which skips over TLVs
until EOT is reached?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Jakub Kicinski @ 2026-04-12 19:55 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <20260407173356.873887-3-christoph.boehmwalder@linbit.com>
On Tue, 7 Apr 2026 19:33:54 +0200 Christoph Böhmwalder wrote:
> The new flags in the genetlink-legacy spec that are required for
> existing consumers to keep working are:
>
> "default": a literal value or C define that sets the default value
> for an attribute, consumed by set_defaults().
>
> "required": if true, from_attrs() returns an error when this
> attribute is missing from the request message.
>
> "nla-policy-type": can be used to override the NLA type used in
> policy arrays. This is needed when the semantic type differs from
> the wire type for backward compatibility: genl_magic maps s32 fields
> to NLA_U32/nla_get_u32, and existing userspace might depend on this
> encoding. The immediate motivation is DRBD, whose genl spec
> definition predates the addition of signed types in genl. However,
> this is a generic issue that potentially affects multiple families:
> for example, nftables has NFTA_HOOK_PRIORITY as s32 in the spec but
> NLA_U32 in the actual kernel policy.
The series doesn't apply for me (neither to Linus's tree nor
to networking trees), so I didn't experiment with this code.
Are the new code gen additions purely for the kernel?
Can we just commit the code they output and leave the YNL itself be?
Every single legacy family has some weird quirks the point of YNL
is to get rid of them, not support them all..
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Jakub Kicinski @ 2026-04-12 19:59 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <20260409183509.0b24dea6@kernel.org>
On Thu, 9 Apr 2026 18:35:09 -0700 Jakub Kicinski wrote:
> On Tue, 7 Apr 2026 12:59:17 -0700 Dipayaan Roy wrote:
> > This behavior is observed on a single platform; other platforms
> > perform better with page_pool fragments, indicating this is not a
> > page_pool issue but platform-specific.
>
> Well, someone has to run some experiments and confirm other ARM
> platforms are not impacted, with data. I was hoping to do it myself
> but doesn't look like that will happen in time for the merge window :(
Please repost with the perf analysis on other commercially available
ARM platform. Something like:
This is a workaround applicable to only some platforms. Modifying
driver X to use a similar workaround on [Ampere Max|nVidia
Grace|Amazon Graviton 3|..] the performance for split pages is
y% higher than when using single pages.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] r8169: Use napi_schedule_irqoff()
From: Heiner Kallweit @ 2026-04-12 20:12 UTC (permalink / raw)
To: Matt Vollrath, netdev; +Cc: edumazet, pabeni, kuba, andrew+netdev, nic_swsd
In-Reply-To: <b6c325ea-8865-4aea-addd-3be2fe178244@gmail.com>
On 12.04.2026 15:51, Matt Vollrath wrote:
> On 4/12/26 07:30, Heiner Kallweit wrote:
>> On 12.04.2026 03:40, Matt Vollrath wrote:
>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>>> index 791277e750ba..4c0ad0de3410 100644
>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>> @@ -4873,7 +4873,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
>>> phy_mac_interrupt(tp->phydev);
>>> rtl_irq_disable(tp);
>>> - napi_schedule(&tp->napi);
>>> + napi_schedule_irqoff(&tp->napi);
>>> out:
>>> rtl_ack_events(tp, status);
>>>
>>
>> Not using napi_schedule_irqoff() here is intentional,
>> see 2734a24e6e5d18522fbf599135c59b82ec9b2c9e.
>
> It looks like forced threading was fixed after your fix
> to mitigate the issue of forced threading not masking
> interrupts.
>
> see 81e2073c175b887398e5bca6c004efa89983f58d
>
> If I understand correctly, this should make
> napi_schedule_irqoff() safe in any interrupt handler.
>
I think 8380c81d5c4fced6f4397795a5ae65758272bbfd needs to be
mentioned too, because only with this change your patch is safe
under PREEMPT_RT. Best extend the commit message based on our
discussion. With that one:
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Luka Gejak @ 2026-04-12 20:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, edumazet, pabeni, netdev, fmaurer, horms, luka.gejak
In-Reply-To: <20260412124558.190c725f@kernel.org>
On April 12, 2026 9:45:58 PM GMT+02:00, Jakub Kicinski <kuba@kernel.org> wrote:
>On Tue, 7 Apr 2026 18:25:01 +0200 luka.gejak@linux.dev wrote:
>> From: Luka Gejak <luka.gejak@linux.dev>
>>
>> Supervision frames are only valid if terminated with a zero-length EOT
>> TLV. The current check fails to reject non-EOT entries as the terminal
>> TLV, potentially allowing malformed supervision traffic.
>>
>> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
>> with a length of zero, and properly linearizing the TLV header before
>> access.
>
>> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
>> index 0aca859c88cb..eb89cc44eac0 100644
>> --- a/net/hsr/hsr_forward.c
>> +++ b/net/hsr/hsr_forward.c
>> @@ -82,35 +82,33 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
>> hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct hsr_sup_payload))
>> return false;
>>
>> - /* Get next tlv */
>> + /* Get next TLV */
>
>The capitalization of the comments makes the real changes in this patch
>harder to spot and follow. Please don't tweak the comments unless you're
>really changing / improving them.
>
>> total_length += hsr_sup_tag->tlv.HSR_TLV_length;
>> - if (!pskb_may_pull(skb, total_length))
>> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
>> return false;
>> skb_pull(skb, total_length);
>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>> skb_push(skb, total_length);
>>
>> - /* if this is a redbox supervision frame we need to verify
>> - * that more data is available
>> - */
>> + /* If this is a RedBox supervision frame, verify additional data */
>> if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
>> - /* tlv length must be a length of a mac address */
>> + /* TLV length must be the size of a MAC address */
>> if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct hsr_sup_payload))
>> return false;
>>
>> - /* make sure another tlv follows */
>> + /* Make sure another TLV follows */
>> total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv->HSR_TLV_length;
>> - if (!pskb_may_pull(skb, total_length))
>> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
>> return false;
>>
>> - /* get next tlv */
>> + /* Get next TLV */
>> skb_pull(skb, total_length);
>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>> skb_push(skb, total_length);
>> }
>>
>> - /* end of tlvs must follow at the end */
>> - if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
>> + /* Supervision frame must end with EOT TLV */
>> + if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
>> hsr_sup_tlv->HSR_TLV_length != 0)
>> return false;
>
>Aren't there more optional TLVs that we don't support?
>You mentioned making sure that the final TLV is a zero-length EOT
>but this check is far stricter.
>
>Should we replace this check with a loop which skips over TLVs
>until EOT is reached?
Hi Jakub,
Thank you for the feedback.
I apologize for the noise in the comments. I will revert all cosmetic
capitalization changes in v6 to keep the diff focused on the logic.
Regarding the TLV loop: I actually implemented a TLV walker in v4 [1]
for this exact reason, but I moved to strict sequential parsing in v5
based on reviewer's feedback to keep the implementation simple. Could
you please check if the approach used in v4 is what you had in mind?
If so, I will rebase that logic onto the memory safety fixes
(pskb_may_pull) from v5 and submit it as v6.
[1] https://lore.kernel.org/netdev/20260401092324.52266-2-luka.gejak@linux.dev/
Best regards,
Luka Gejak
^ permalink raw reply
* Re: [PATCH v2 net] net: ax25: fix integer overflow in ax25_rx_fragment()
From: Jakub Kicinski @ 2026-04-12 20:17 UTC (permalink / raw)
To: Mashiro Chen
Cc: netdev, davem, edumazet, pabeni, horms, jreuter, linux-hams,
linux-kernel, stable
In-Reply-To: <20260409025026.24575-1-mashiro.chen@mailbox.org>
On Thu, 9 Apr 2026 10:50:26 +0800 Mashiro Chen wrote:
> Fix mirrors the identical bug fixed in NET/ROM (nr_in.c): check for
> overflow before adding skb->len to fraglen, and abort fragment
> reassembly cleanly if the limit would be exceeded.
Same problem as reported by Simon on the netrom patch applies here.
nit: I don't think you need to cast ax25->fraglen to unsigned int
in the comparison. since it's added with skb->len it should get
auto-prompted to unsigned int.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] net: rose: reject truncated CLEAR_REQUEST frames in state machines
From: patchwork-bot+netdevbpf @ 2026-04-12 20:20 UTC (permalink / raw)
To: Mashiro Chen
Cc: netdev, davem, edumazet, kuba, pabeni, horms, linux-hams,
linux-kernel, stable
In-Reply-To: <20260408172551.281486-1-mashiro.chen@mailbox.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 01:25:51 +0800 you wrote:
> All five ROSE state machines (states 1-5) handle ROSE_CLEAR_REQUEST
> by reading the cause and diagnostic bytes directly from skb->data[3]
> and skb->data[4] without verifying that the frame is long enough:
>
> rose_disconnect(sk, ..., skb->data[3], skb->data[4]);
>
> The entry-point check in rose_route_frame() only enforces
> ROSE_MIN_LEN (3 bytes), so a remote peer on a ROSE network can
> send a syntactically valid but truncated CLEAR_REQUEST (3 or 4
> bytes) while a connection is open in any state. Processing such a
> frame causes a one- or two-byte out-of-bounds read past the skb
> data, leaking uninitialized heap content as the cause/diagnostic
> values returned to user space via getsockopt(ROSE_GETCAUSE).
>
> [...]
Here is the summary with links:
- [net] net: rose: reject truncated CLEAR_REQUEST frames in state machines
https://git.kernel.org/netdev/net/c/2835750dd647
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 0/5] net: enetc: improve statistics for v1 and add statistics for v4
From: patchwork-bot+netdevbpf @ 2026-04-12 20:20 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, netdev, linux-kernel, imx
In-Reply-To: <20260408055849.1314033-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 13:58:44 +0800 you wrote:
> For ENETC v1, some standardized statistics were redundantly included in
> the unstructured statistics, so remove these duplicated entries.
> Previously, the unstructured statistics only contained eMAC data and
> did not include pMAC data; add pMAC statistics to ensure completeness.
>
> For ENETC v4, the driver previously reported MAC statistics only for the
> internal ENETC (Pseudo MAC). Extend the implementation to provide
> additional statistics for both the internal ENETC and the standalone
> ENETC.
>
> [...]
Here is the summary with links:
- [net-next,1/5] net: enetc: add support for the standardized counters
https://git.kernel.org/netdev/net-next/c/c6c223fd06ed
- [net-next,2/5] net: enetc: show RX drop counters only for assigned RX rings
https://git.kernel.org/netdev/net-next/c/c571d309d4cf
- [net-next,3/5] net: enetc: remove standardized counters from enetc_pm_counters
https://git.kernel.org/netdev/net-next/c/6d78c37a73e0
- [net-next,4/5] net: enetc: add unstructured pMAC counters for ENETC v1
https://git.kernel.org/netdev/net-next/c/dbc30b154e33
- [net-next,5/5] net: enetc: add unstructured counters for ENETC v4
https://git.kernel.org/netdev/net-next/c/98a4f3d34132
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 net 0/2] net: hamradio: fix missing input validation in bpqether and scc
From: patchwork-bot+netdevbpf @ 2026-04-12 20:30 UTC (permalink / raw)
To: Mashiro Chen
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni, jreuter,
linux-hams, linux-kernel
In-Reply-To: <20260409024927.24397-1-mashiro.chen@mailbox.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 10:49:25 +0800 you wrote:
> This series fixes two missing input validation bugs in the hamradio
> drivers. Both patches were reviewed by Joerg Reuter (hamradio
> maintainer).
>
> v2 changes:
> - bpqether: no code change; add Acked-by: Joerg Reuter
> - scc: drop the upper bound of 4096 per reviewer feedback;
> only enforce the minimum of 16
>
> [...]
Here is the summary with links:
- [v2,net,1/2] net: hamradio: bpqether: validate frame length in bpq_rcv()
https://git.kernel.org/netdev/net/c/6183bd8723a3
- [v2,net,2/2] net: hamradio: scc: validate bufsize in SIOCSCCSMEM ioctl
https://git.kernel.org/netdev/net/c/8263e484d662
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 v5 1/2] net: hsr: require valid EOT supervision TLV
From: Jakub Kicinski @ 2026-04-12 20:31 UTC (permalink / raw)
To: Luka Gejak; +Cc: davem, edumazet, pabeni, netdev, fmaurer, horms
In-Reply-To: <DDF9CC02-6FC1-44F0-B95D-967151BF0592@linux.dev>
On Sun, 12 Apr 2026 22:13:35 +0200 Luka Gejak wrote:
> Regarding the TLV loop: I actually implemented a TLV walker in v4 [1]
> for this exact reason, but I moved to strict sequential parsing in v5
> based on reviewer's feedback to keep the implementation simple. Could
> you please check if the approach used in v4 is what you had in mind?
> If so, I will rebase that logic onto the memory safety fixes
> (pskb_may_pull) from v5 and submit it as v6.
That's not really what I had in mind. I was thinking of a loop which
just skips the TLVs in order, leaving the parsing of known TLVs as is.
But I've never used HSR maybe this sort of strict validation is somehow
okay in HSR deployments.
Please just undo the comment tweaks then.
^ permalink raw reply
* RE: [PATCH net] net: ethernet: ravb: Do not check URAM suspension when WoL is active
From: Sai Krishna Gajula @ 2026-04-12 20:38 UTC (permalink / raw)
To: Niklas Söderlund, Paul Barker, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Yoshihiro Shimoda,
Geert Uytterhoeven, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20260412173213.3179426-1-niklas.soderlund+renesas@ragnatech.se>
> -----Original Message-----
> From: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Sent: Sunday, April 12, 2026 11:02 PM
> To: Paul Barker <paul@pbarker.dev>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Geert Uytterhoeven <geert@linux-
> m68k.org>; netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org
> Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Subject: [PATCH net] net: ethernet: ravb: Do not check URAM
> suspension when WoL is active
>
> When updating the driver to match latest datasheet to suspend access to
> URAM when suspending DMA transfers a corner-case was missed, URAM
> access will not be suspended if WoL is enabled. This lead to the error
> message (correctly) being triggered
> When updating the driver to match latest datasheet to suspend access to
> URAM when suspending DMA transfers a corner-case was missed, URAM
> access will not be suspended if WoL is enabled. This lead to the error
> message
> (correctly) being triggered as URAM access is not suspended even tho it's
> requested as part of stopping DMA.
>
> Avoid checking if URAM access is suspended and printing the error message if
> WoL is enabled when we suspend the system, as we know it will not be.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Closes: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lore.kernel.org_all_CAMuHMdWnjV-
> 253DHGE1o08zLhUfTgOSene5fYx1J5GG10mB-252BToq8qg-
> 40mail.gmail.com_&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=c3MsgrR-
> U-HFhmFd6R4MWRZG-8QeikJn5PkjqMTpBSg&m=zcNb0FL70yebEHmL9-
> Sb2w05J7NxodKS6m5O_dpUxTZVY_5wbpd-
> Pls5yPmFMa4D&s=unSmIn3N04eAyEfuFm7ADIhCkckecCQL2hGzpgeEdQc&e=
> Fixes: 353d8e7989b6 ("net: ethernet: ravb: Suspend and resume the
> transmission flow")
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> b/drivers/net/ethernet/renesas/ravb_main.c
> index 1dbfadb2a881..5f88733094d0 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1108,9 +1108,12 @@ static int ravb_stop_dma(struct net_device *ndev)
>
> /* Request for transmission suspension */
> ravb_modify(ndev, CCC, CCC_DTSR, CCC_DTSR);
> - error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
> - if (error)
> - netdev_err(ndev, "failed to stop AXI BUS\n");
> + /* Access to URAM will not be suspended if WoL is enabled. */
> + if (!priv->wol_enabled) {
> + error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
> + if (error)
> + netdev_err(ndev, "failed to stop AXI BUS\n");
> + }
>
> /* Stop AVB-DMAC process */
> return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
> --
> 2.53.0
>
Reviewed-by: Sai Krishna <saikrishnag@marvell.com>
^ permalink raw reply
* Re: [PATCH v2] nfc: hci: fix OOB heap read on short HCP frames
From: Jakub Kicinski @ 2026-04-12 20:42 UTC (permalink / raw)
To: Ashutosh Desai; +Cc: netdev, Eric Dumazet, davem, pabeni, horms, linux-kernel
In-Reply-To: <20260409150825.2217133-1-ashutoshdesai993@gmail.com>
On Thu, 9 Apr 2026 15:08:25 +0000 Ashutosh Desai wrote:
> Suggested-by: Eric Dumazet <edumazet@google.com>
As Eric mentioned elsewhere - he did not suggest any of this,
merely reviewed your submission.
> +++ b/net/nfc/hci/core.c
> @@ -134,6 +134,10 @@ static void nfc_hci_msg_rx_work(struct work_struct *work)
> u8 instruction;
>
> while ((skb = skb_dequeue(&hdev->msg_rx_queue)) != NULL) {
> + if (!pskb_may_pull(skb, NFC_HCI_HCP_HEADER_LEN)) {
> + kfree_skb(skb);
> + continue;
How did a broken packet get enqueued in the first place?
^ permalink raw reply
* Re: [PATCH net-next v18 00/15] Begin upstreaming Homa transport protocol
From: Jakub Kicinski @ 2026-04-12 20:45 UTC (permalink / raw)
To: John Ousterhout; +Cc: netdev, pabeni, edumazet, horms
In-Reply-To: <20260410200310.1915-1-ouster@cs.stanford.edu>
On Fri, 10 Apr 2026 13:02:54 -0700 John Ousterhout wrote:
> This patch series begins the process of upstreaming the Homa transport
> protocol. Homa is an alternative to TCP for use in datacenter
> environments. It provides 10-100x reductions in tail latency for short
> messages relative to TCP. Its benefits are greatest for mixed workloads
> containing both short and long messages running under high network loads.
> Homa is not API-compatible with TCP: it is connectionless and message-
> oriented (but still reliable and flow-controlled). Homa's new API not
> only contributes to its performance gains, but it also eliminates the
> massive amount of connection state required by TCP for highly connected
> datacenter workloads (Homa uses ~ 1 socket per application, whereas
> TCP requires a separate socket for each peer).
make coccicheck says:
net/homa/homa_peer.c:213:21-22: WARNING opportunity for swap()
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Luka Gejak @ 2026-04-12 20:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, edumazet, pabeni, netdev, fmaurer, horms, luka.gejak
In-Reply-To: <20260412133157.3b335e1b@kernel.org>
On April 12, 2026 10:31:57 PM GMT+02:00, Jakub Kicinski <kuba@kernel.org> wrote:
>On Sun, 12 Apr 2026 22:13:35 +0200 Luka Gejak wrote:
>> Regarding the TLV loop: I actually implemented a TLV walker in v4 [1]
>> for this exact reason, but I moved to strict sequential parsing in v5
>> based on reviewer's feedback to keep the implementation simple. Could
>> you please check if the approach used in v4 is what you had in mind?
>> If so, I will rebase that logic onto the memory safety fixes
>> (pskb_may_pull) from v5 and submit it as v6.
>
>That's not really what I had in mind. I was thinking of a loop which
>just skips the TLVs in order, leaving the parsing of known TLVs as is.
>But I've never used HSR maybe this sort of strict validation is somehow
>okay in HSR deployments.
>
>Please just undo the comment tweaks then.
So keep other changes as is and only undo comment changes?
^ permalink raw reply
* Re: [PATCH net v2 0/2] net/rds: Fix use-after-free in RDS/IB for non-init namespaces
From: patchwork-bot+netdevbpf @ 2026-04-12 20:50 UTC (permalink / raw)
To: Allison Henderson
Cc: netdev, pabeni, edumazet, rds-devel, kuba, horms, linux-rdma
In-Reply-To: <20260408080420.540032-1-achender@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 01:04:18 -0700 you wrote:
> This series fixes syzbot bug da8e060735ae02c8f3d1
> https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1
>
> The report finds a use-after-free bug where ib connections access an
> invalid network namespace after it has been freed. The stack is:
>
> rds_rdma_cm_event_handler_cmn
> rds_conn_path_drop
> rds_destroy_pending
> check_net() <-- use-after-free
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net/rds: Optimize rds_ib_laddr_check
https://git.kernel.org/netdev/net/c/236f718ac885
- [net,v2,2/2] net/rds: Restrict use of RDS/IB to the initial network namespace
https://git.kernel.org/netdev/net/c/ebf71dd4aff4
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 v3] ppp: require CAP_NET_ADMIN in target netns for unattached ioctls
From: patchwork-bot+netdevbpf @ 2026-04-12 20:50 UTC (permalink / raw)
To: =?utf-8?b?7ZWY7YOc6rWsIDxoYXRhZWd1MDgyNkBnbWFpbC5jb20+?=
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, dqfext, kees,
kuniyu, bigeasy, gorcunov, linux-ppp, netdev, linux-kernel,
qingfang.deng, gnault, jaco, richardbgobert, ericwouds,
teknoraver
In-Reply-To: <20260409071117.4354-1-hataegu0826@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 16:11:15 +0900 you wrote:
> /dev/ppp open is currently authorized against file->f_cred->user_ns,
> while unattached administrative ioctls operate on current->nsproxy->net_ns.
>
> As a result, a local unprivileged user can create a new user namespace
> with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,
> and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against
> an inherited network namespace.
>
> [...]
Here is the summary with links:
- [net,v3] ppp: require CAP_NET_ADMIN in target netns for unattached ioctls
https://git.kernel.org/netdev/net/c/2bb6379416fd
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 net-next 00/15] ip6mr: No RTNL for RTNL_FAMILY_IP6MR rtnetlink.
From: Kuniyuki Iwashima @ 2026-04-12 20:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, David Ahern, Eric Dumazet, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <20260412075856.68f37eb6@kernel.org>
On Sun, Apr 12, 2026 at 7:58 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 10 Apr 2026 21:16:56 +0000 Kuniyuki Iwashima wrote:
> > This series is the IPv6 version of
> >
> > https://lore.kernel.org/netdev/20260228221800.1082070-1-kuniyu@google.com/
> >
> > and removes RTNL from ip6mr rtnetlink handlers.
> >
> > After this series, there are a few RTNL left in net/ipv6/ipmr.c
> > and such users will be converted to per-netns RTNL in another
> > series.
> >
> > Patch 1 extends the ipmr selftest to exercise most of the RTNL
> > paths in net/ipv6/ipmr.c
> >
> > Patch 2 - 6 converts RTM_GETROUTE handlers to RCU.
> >
> > Patch 7 removes struct fib_dump_filter.rtnl_held.
> >
> > Patch 8 - 9 use RCU for mr_table for CONFIG_IP_MROUTE_MULTIPLE_TABLES=n
> > and CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=n for ->exit_rtnl().
> >
> > Patch 10 - 12 converts ->exit_batch() to ->exit_rtnl() to
> > save one RTNL in cleanup_net().
> >
> > Patch 13 - 14 removes unnecessary RTNL during setup_net()
> > failure.
> >
> > Patch 15 drops RTNL for MRT6_(ADD|DEL)_MFC(_PROXY)?.
>
> Hitting a bunch of:
>
> SKIP no netlink MFC interface
>
> on the new test here. Do we need to add something to .../config ?
No, I used SKIP() intentionally becuase only IPv4 has the MFC
netlink interface and IPv6 does not have the corresponding one.
Should I just return 0 in this case instead of SKIP() ?
^ permalink raw reply
* Re: [PATCH v1 net-next] selftest: net: Use port outside of the default ip_local_ports in csum.c.
From: Kuniyuki Iwashima @ 2026-04-12 20:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Willem de Bruijn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Willem de Bruijn, Mahesh Bandewar,
Kuniyuki Iwashima, netdev
In-Reply-To: <20260412094729.334b8890@kernel.org>
On Sun, Apr 12, 2026 at 9:47 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sat, 11 Apr 2026 15:18:56 -0400 Willem de Bruijn wrote:
> > > diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
> > > index e28884ce3ab3..4e044689bc37 100644
> > > --- a/tools/testing/selftests/net/lib/csum.c
> > > +++ b/tools/testing/selftests/net/lib/csum.c
> > > @@ -105,9 +105,9 @@ static char *cfg_mac_src;
> > > static int cfg_proto = IPPROTO_UDP;
> > > static int cfg_payload_char = 'a';
> > > static int cfg_payload_len = 100;
> > > -static uint16_t cfg_port_dst = 34000;
> >
> > This is paired with wait_port_listen(3400, .. in
> > tools/testing/selftests/drivers/net/hw/csum.py
>
> FWIW I can confirm that this caused the HW testing in NIPA to fail
> the csum test since Friday.
Sorry, I'll cover that part and try the port option.
^ permalink raw reply
* Re: [PATCH net 1/4] nfc: digital: Fix stack buffer overflow in digital_in_recv_sensf_res()
From: Jakub Kicinski @ 2026-04-12 20:58 UTC (permalink / raw)
To: Lekë Hapçiu; +Cc: netdev, linux-wireless, stable, krzysztof.kozlowski
In-Reply-To: <20260409223436.1887988-2-snowwlake@icloud.com>
On Fri, 10 Apr 2026 00:34:31 +0200 Lekë Hapçiu wrote:
> The function digital_in_recv_sensf_res() validates that the incoming
> SENSF_RES frame is at least DIGITAL_SENSF_RES_MIN_LENGTH (17) bytes,
> but does not check that it is at most NFC_SENSF_RES_MAXSIZE (18) bytes
> before copying into the 18-byte target.sensf_res stack buffer.
Hm, third similar fix we received for this.
struct digital_sensf_res is 19 bytes, you're capping the length at 18
something else is wrong here..
^ permalink raw reply
* Re: [PATCH net 0/2] More fixes for the IPA driver
From: patchwork-bot+netdevbpf @ 2026-04-12 21:00 UTC (permalink / raw)
To: Luca Weiss
Cc: elder, andrew+netdev, davem, edumazet, kuba, pabeni,
~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel
In-Reply-To: <20260409-ipa-fixes-v1-0-a817c30678ac@fairphone.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 09 Apr 2026 10:13:30 +0200 you wrote:
> Two more fixes for the Qualcomm IPA driver.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Luca Weiss (2):
> net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
> net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
>
> [...]
Here is the summary with links:
- [net,1/2] net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
https://git.kernel.org/netdev/net/c/de08f9585692
- [net,2/2] net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
https://git.kernel.org/netdev/net/c/1335b903cf2e
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] octeon_ep: Remove unnecessary semicolons in octep_oq_drop_rx()
From: patchwork-bot+netdevbpf @ 2026-04-12 21:00 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: vburru, sedara, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev
In-Reply-To: <1775711291-13938-1-git-send-email-nobuhiro.iwamatsu.x90@mail.toshiba>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 14:08:11 +0900 you wrote:
> Remove unnecessary semicolons in octep_oq_drop_rx().
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
> ---
> drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- octeon_ep: Remove unnecessary semicolons in octep_oq_drop_rx()
https://git.kernel.org/netdev/net-next/c/21ad19a99d94
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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