netdev - RE: possible bug in latest network tree

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: <660C7E53FDDFB64C8741117E0D659AAAB8463B9F@ORSMSX116.amr.corp.intel.com>
Date:	Wed, 30 Mar 2016 21:05:30 +0000
From:	"Light, John J" <john.j.light@...el.com>
To:	"David S. Miller" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: possible bug in latest network tree

David,

I see a recent change in inet_connection_sock.c that uses sysctl_tcp_synack_retries suspiciously.

Previously, sysctl_tcp_synack_retries was a global variable, and now it has been moved into the fragment (really netns_ipv4).

In reqsk_timer_handler (inet_connection_sock.c) near line 563 it is used as the default max_retries value in case icsk->icsk_syn_retries is not set.

Previously, other transports (dccp?) would use the TCP global variable as a default.  Now that the defaults come from the fragment, I suspect the fragment variable is not set for other transports.  (I can't find where it's set for dccp.)

Of course, this will only show in non-TCP transport protocols when the icsk retries value is not set, so it's a rare case.  Perhaps it's an unreachable case, since I don't know all the kernel paths.

Maybe the problem is that the default shouldn't be to a TCP value, but should be a 'transport' value.

This code is somewhat convoluted, so I am not sure of my analysis, but I wanted you to consider it.

John Light
Intel OTC comms