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-next>] [day] [month] [year] [list]
Message-ID: <CAHD5p1U5vrrcT1QpqPDwEgQJANdX67N-j0Hy4sh2ED+6BPMstQ@mail.gmail.com>
Date: Thu, 18 Sep 2025 08:54:49 +0530
From: CHANDRA SEKHAR REDDY <ccsr007@...il.com>
To: "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: [REGRESSION] v5.15: UDP packets not fragmented after receiving ICMP
 "Fragmentation Needed" (works in v5.10)

Hi Team,

We are observing an intermittent regression in UDP fragmentation
handling between Linux kernel versions v5.10.35 and v5.15.71.

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.

Best regards,
Chandrasekharreddy C

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ