[PATCH 0/1] net/ipv4: discard icmp timestamp requests

[PATCH 0/1] net/ipv4: discard icmp timestamp requests

[jch]

If you google "CVE-1999-0524 fix" you'll see quite a few comments along the
lines "this recently showed up in vulnerability scans, this is how I fixed
it".  It shows up because in late 2022, the CVSS score for that CVE changed
from 0.0 to 2.1.  There are actually two part to this: one relates to
disclosing address information (which is long gone from linux) and the
other relates to disclosing timestamp information.

This is regarded a a vulnerability because it allows you see the host's
count of the number of milliseconds since midnight.  Indeed, according to
RFC 0792, and back in 1981 it had a potential use for time synchronisation
across hosts.  That early use-case has long since been supplanted by NTP so
you know how many milliseconds there are since midnight: it's the same as
on your host, your smartwatch, your phone and practically any other
computer you care to mention.

It's not as though the ICMP timestamp is an actual vulnerability, it's just
a pain in the neck because world+dog wants to know how to configure
iptables or nft to just discard this, so let's help everyone out by
discarding it in the kernel.

jch

John Haxby (1):
  net/ipv4: discard icmp timestamp requests

 net/ipv4/icmp.c | 42 +-----------------------------------------
 1 file changed, 1 insertion(+), 41 deletions(-)

-- 
2.55.0

[PATCH 1/1] net/ipv4: discard icmp timestamp requests

[jch]

An icmp timestamp request is classed a a minor security vulnerability
(CVE-1999-0524) due to an information leak.  As pretty much everything
uses NTP these days, it's not as though this is an actual problem but
scanners flag this so for everyone's sake, let's just discard timestamp
requests.

Signed-off-by: John Haxby <jch@thehaxbys.co.uk>
---
 net/ipv4/icmp.c | 42 +-----------------------------------------
 1 file changed, 1 insertion(+), 41 deletions(-)

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 23e921d313b3..ec0443424110 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -1383,46 +1383,6 @@ bool icmp_build_probe(struct sk_buff *skb, struct icmphdr *icmphdr)
 	return true;
 }
 
-/*
- *	Handle ICMP Timestamp requests.
- *	RFC 1122: 3.2.2.8 MAY implement ICMP timestamp requests.
- *		  SHOULD be in the kernel for minimum random latency.
- *		  MUST be accurate to a few minutes.
- *		  MUST be updated at least at 15Hz.
- */
-static enum skb_drop_reason icmp_timestamp(struct sk_buff *skb)
-{
-	DEFINE_RAW_FLEX(struct icmp_bxm, icmp_param, replyopts.opt.__data,
-			IP_OPTIONS_DATA_FIXED_SIZE);
-	/*
-	 *	Too short.
-	 */
-	if (skb->len < 4)
-		goto out_err;
-
-	/*
-	 *	Fill in the current time as ms since midnight UT:
-	 */
-	icmp_param->data.times[1] = inet_current_timestamp();
-	icmp_param->data.times[2] = icmp_param->data.times[1];
-
-	BUG_ON(skb_copy_bits(skb, 0, &icmp_param->data.times[0], 4));
-
-	icmp_param->data.icmph	   = *icmp_hdr(skb);
-	icmp_param->data.icmph.type = ICMP_TIMESTAMPREPLY;
-	icmp_param->data.icmph.code = 0;
-	icmp_param->skb		   = skb;
-	icmp_param->offset	   = 0;
-	icmp_param->data_len	   = 0;
-	icmp_param->head_len	   = sizeof(struct icmphdr) + 12;
-	icmp_reply(icmp_param, skb);
-	return SKB_NOT_DROPPED_YET;
-
-out_err:
-	__ICMP_INC_STATS(skb_dst_dev_net_rcu(skb), ICMP_MIB_INERRORS);
-	return SKB_DROP_REASON_PKT_TOO_SMALL;
-}
-
 static enum skb_drop_reason icmp_discard(struct sk_buff *skb)
 {
 	/* pretend it was a success */
@@ -1685,7 +1645,7 @@ static const struct icmp_control icmp_pointers[NR_ICMP_TYPES + 1] = {
 		.error = 1,
 	},
 	[ICMP_TIMESTAMP] = {
-		.handler = icmp_timestamp,
+		.handler = icmp_discard,
 	},
 	[ICMP_TIMESTAMPREPLY] = {
 		.handler = icmp_discard,
-- 
2.55.0

Re: [PATCH 1/1] net/ipv4: discard icmp timestamp requests

[Ido Schimmel]

On Wed, Jul 22, 2026 at 11:24:41AM +0100, jch@thehaxbys.co.uk wrote:
> An icmp timestamp request is classed a a minor security vulnerability
> (CVE-1999-0524) due to an information leak.  As pretty much everything
> uses NTP these days, it's not as though this is an actual problem but
> scanners flag this so for everyone's sake, let's just discard timestamp
> requests.

The idea was discussed in the past and was rejected:

https://lore.kernel.org/netdev/1557711193-7284-1-git-send-email-chenweilong@huawei.com/
https://lore.kernel.org/netdev/1557754137-100816-1-git-send-email-chenweilong@huawei.com/
https://lore.kernel.org/netdev/20240520165335899feIJEvG6iuT4f7FBU6ctk@zte.com.cn/

I don't see a reason to revisit this.

Re: [PATCH 1/1] net/ipv4: discard icmp timestamp requests

[John Haxby]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]



> On 23 Jul 2026, at 10:08, Ido Schimmel <idosch@nvidia.com> wrote:
> 
> On Wed, Jul 22, 2026 at 11:24:41AM +0100, jch@thehaxbys.co.uk wrote:
>> An icmp timestamp request is classed a a minor security vulnerability
>> (CVE-1999-0524) due to an information leak.  As pretty much everything
>> uses NTP these days, it's not as though this is an actual problem but
>> scanners flag this so for everyone's sake, let's just discard timestamp
>> requests.
> 
> The idea was discussed in the past and was rejected:
> 
> https://lore.kernel.org/netdev/1557711193-7284-1-git-send-email-chenweilong@huawei.com/
> https://lore.kernel.org/netdev/1557754137-100816-1-git-send-email-chenweilong@huawei.com/
> https://lore.kernel.org/netdev/20240520165335899feIJEvG6iuT4f7FBU6ctk@zte.com.cn/
> 
> I don't see a reason to revisit this.

In fact, there is a reason to revisit this.  CVE-1999-0524 went from having a CVSS score of 0.0 (ie not a vulnerability) to CVSS2 score 2.1 in 2022 and today it has a CVSS3.x score of 4.0.   Those first two links are messages in 2019, well before there was a non-zero score.  The last link is, admittedly, 2024 but rather than completely removing ICMP timestamp (as was done with ICMP address, the other part of CVE-1999-0524) is provides a sysctl to turn it off.   I wasn't aware of that possible patch, but it assumes that there's a use-case for ICMP timestamp and in the few years I've been aware of this as an issue (in my previous job) I haven't found one.

Admittedly, it's easy to just disable the timestamp in a firewall (eg firewall-cmd --add-icmp-block=timestamp-request) but people have to discover that after a scanner has screamed warnings about unfixed vulnerabilities.  So now I have actual time on my hands not dealing with the daily firefight of kernel CVEs, I had time to actually do something about this that's been annoying me and quite a lot of other people -- I mentioned googling for "CVE-1999-0524 fix".

If there's a genuine use-case for ICMP timestamp, then yes, it should stay and we'll just add to the documentation from Cisco, f5, Dell, Oracle, etc to explain how to disable it if you don't have that use case.  But lacking a use-case, I still think ICMP timestamp should simply be consigned to the bin.

jch

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]