<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Time-matching extension (--match time) broken by timestamping changes in kernel 4.20 and later"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1332">1332</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Time-matching extension (--match time) broken by timestamping changes in kernel 4.20 and later
</td>
</tr>
<tr>
<th>Product</th>
<td>netfilter/iptables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>ip_tables (kernel)
</td>
</tr>
<tr>
<th>Assignee</th>
<td>netfilter-buglog@lists.netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>stuben@iki.fi
</td>
</tr></table>
<p>
<div>
<pre>Changes made to socket buffer timestamping (starting in kernel 4.20) will break
the functionality of the time-matching extension for iptables. Specifically,
the kernel patch called "tcp: provide earliest departure time in skb->tstamp"
[1] will result in the 'skb->tstamp' NOT being zeroed before entering the IP
stack. This change was introduced (in "net/ipv4/tcp_output.c") with the
following patch:
- /* Our usage of tstamp should remain private */
- skb->tstamp = 0;
+ /* Leave earliest departure time in skb->tstamp (skb->skb_mstamp_ns) */
Now that the timestamp no longer is cleared, this will end up causing incorrect
matching in function 'time_mt()' (in "net/netfilter/xt_time.c"). The "problem"
is present in the following two lines of code:
if (skb->tstamp == 0)
__net_timestamp((struct sk_buff *)skb);
The above code will check if the packet already has a timestamp or not. If the
timestamp is missing, then the packet is timestamped with the current time. All
subsequent time matching calculations then assume that the packet's timestamp
is relative to the UNIX epoch (CLOCK_REALTIME reference). This all works fine,
as long as the timestamp explicitly has been set in xt_time. But the same
assumption on clock reference might not hold, if the packet comes in
pre-timestamped. And this is exactly what is happening in kernel 4.20.x and
later. Here the packets come in with a timestamp but that timestamp is not
based on current time but rather on CLOCK_MONOTONIC reference (i.e., time since
system boot).
I have verified this problem on kernel versions 4.19.6 (works) and 4.20.17
(broken). I have used prebuilt kernels for Fedora, but I do not think this is a
distribution specific problem. iptables is at version 1.8.0.
Steps to reproduce:
1) flush/delete all iptables rules and set all chains to ACCEPT
2) add a rule with time matching (e.g, 'iptables -A OUTPUT -d example.com
--match time --timestart <five minutes ago UTC> --timestop <five minutes in the
future UTC> -j DROP')
3) verify that packets to example.com are correctly dropped on 4.19.6
4) verify that packets to example.com are NOT dropped on 4.20.17
5) reintroduce 'skb->tstamp = 0;' in "net/ipv4/tcp_output.c", recompile kernel
4.20.17, and verify that packets now are being correctly dropped
I am not an expert on kernel internals and timestamping so I guess you need to
decide on how to fix this. A quick and dirty fix could be to never rely on
packet timestamps but always use current time as a matching reference.
[1]
<a href="https://github.com/torvalds/linux/commit/d3edd06ea8ea9e03de6567fda80b8be57e21a537#diff-2122118b70cbae1a5831191239717312">https://github.com/torvalds/linux/commit/d3edd06ea8ea9e03de6567fda80b8be57e21a537#diff-2122118b70cbae1a5831191239717312</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>