CVE-2023-53635

In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: fix wrong ct->timeout value

(struct nf_conn)->timeout is an interval before the conntrack confirmed. After confirmed, it becomes a timestamp.

It is observed that timeout of an unconfirmed conntrack:

• Set by calling ctnetlink_change_timeout(). As a result, nfct_time_stamp was wrongly added to ct->timeout twice.
• Get by calling ctnetlink_dump_timeout(). As a result, nfct_time_stamp was wrongly subtracted.

Call Trace: <TASK> dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsg

Separate the 2 cases in:

• Setting ct->timeout in __nf_ct_set_timeout().
• Getting ct->timeout in ctnetlink_dump_timeout().

Pablo appends:

Update ctnetlink to set up the timeout after the IPS_CONFIRMED flag is set on, otherwise conntrack creation via ctnetlink breaks.

Note that the problem described in this patch occurs since the introduction of the nfnetlink_queue conntrack support, select a sufficiently old Fixes: tag for -stable kernel to pick up this fix.

Conntrack timeout was miscomputed by mixing an interval (pre-confirm) with a timestamp (post-confirm), adding/subtracting nfct_time_stamp incorrectly. A local actor with CAP_NET_ADMIN (e.g., via ctnetlink) could cause stuck or prematurely expiring entries, impacting availability via conntrack table growth or drops.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.