lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <26786cc6-79cf-4f6c-a217-d1358aacfcc0@oracle.com>
Date: Thu, 18 Sep 2025 10:39:08 +0530
From: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>
To: CHANDRA SEKHAR REDDY <ccsr007@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "arun85.m@...il.com" <arun85.m@...il.com>
Subject: Re: [REGRESSION] v5.15: UDP packets not fragmented after receiving
 ICMP "Fragmentation Needed" (works in v5.10)

Hi Chandra Sekhar,

 From a stable kernels point of view I have some comments.

On 18/09/25 08:54, CHANDRA SEKHAR REDDY wrote:
> Hi Team,
> 
> We are observing an intermittent regression in UDP fragmentation
> handling between Linux kernel versions v5.10.35 and v5.15.71.
> 


These both are like really old stable kernels. Can you try with the 
latest stable kernels ?

5.15.193 and 5.10.244 ?

If you could reproduce the same on 5.15.193, maybe we should try on 
different kernels to understand the cause better (i.e 5.15.0 and then 
narrow it if needed)


> Problem description:
> Our application sends UDP packets that exceed the path MTU. An
> intermediate hop returns an ICMP Type 3, Code 4 (Fragmentation Needed)
> message.
> 
> On v5.10.35, the kernel correctly updates the Path MTU cache, and
> subsequent packets are fragmented as expected.
> 
> On v5.15.71, although the ICMP message is received by the kernel,
> subsequent UDP packets are sometimes not fragmented and continue to be
> dropped.
> 
> System details:
> 
> Egress interface MTU: 9192 bytes
> 
> Path MTU at intermediate hop: 1500 bytes
> 
> Kernel parameter: ip_no_pmtu_disc=0 (default)
> 
> Questions / request for feedback:
> 
> Is this a known regression in the 5.15 kernel series?
> 
> We have verified that the Path MTU cache is usually updated correctly.
> 
> Is there a way to detect or log cases where the cache is not updated?
> 
> If this issue has already been addressed, could you please point us to
> the relevant fix commit so we can backport and test it?
> 
> We have reviewed several patches between v5.10.35 and v5.15.71 related
> to PMTU and ICMP handling and examined the code flow,
>   but have not been able to pinpoint the root cause.
> 
> Any guidance, insights, or pointers would be greatly appreciated.
> 

Thanks,
Harshit

> Best regards,
> Chandrasekharreddy C
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ