netdev - Re: sk->sk_socket seems to disappear before connection termination

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.01.1011101148060.18018@obet.zrqbmnf.qr>
Date:	Wed, 10 Nov 2010 11:53:48 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	David Howells <dhowells@...hat.com>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>, netdev@...r.kernel.org,
	Rafał Maj <rafal.maj.it@...il.com>
Subject: Re: sk->sk_socket seems to disappear before connection termination

On Wednesday 2010-11-10 06:47, Eric Dumazet wrote:
>Le mercredi 10 novembre 2010 à 02:09 +0100, Jan Engelhardt a écrit :
>> Hi,
>> 
>> Rafał reported this to us on IRC, paraphrasing what has been observed:
>> 
>> Using a simple rule like `iptables -A OUTPUT -p tcp --dport 80 -j LOG 
>> --log-uid`, one can observe on creating a connection and terminating
>> it that the trailing packets have skb->sk->sk_socket == NULL.
>> Is this intended? Is the socket not retained until after TCP has
>> sent out the closing exchange?
>> 
>> As I can reproduce:
>> 
>> $ telnet 134.76.13.21 80
>> Trying 134.76.13.21...
>> Connected to 134.76.13.21.
>> Escape character is '^]'.
>> ^]
>> telnet> ^D
>> Connection closed.
>> 
>> [491419.500978] IN= OUT=tun0 SRC=134.76.2.163 DST=134.76.13.21 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=35420 DF PROTO=TCP SPT=58613 DPT=80 WINDOW=5488 RES=0x00 SYN URGP=0 UID=25121 GID=100 
>> [491419.511533] IN= OUT=tun0 SRC=134.76.2.163 DST=134.76.13.21 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=35421 DF PROTO=TCP SPT=58613 DPT=80 WINDOW=86 RES=0x00 ACK URGP=0 UID=25121 GID=100 
>> [491420.052182] IN= OUT=tun0 SRC=134.76.2.163 DST=134.76.13.21 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=35422 DF PROTO=TCP SPT=58613 DPT=80 WINDOW=86 RES=0x00 ACK FIN URGP=0 UID=25121 GID=100 
>> [491420.063619] IN= OUT=tun0 SRC=134.76.2.163 DST=134.76.13.21 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=35423 DF PROTO=TCP SPT=58613 DPT=80 WINDOW=86 RES=0x00 ACK URGP=0 
>
>Hmmm... skb->sk->sk_socket is really NULL ?
>Are you sure its not skb->sk->sk_socket->file which is NULL ?

I am certain of it, having augmented ipt_LOG/xt_LOGMARK temporarily by 
appropriate printks.

>In this case, you might need to use sock_i_uid() / sock_i_ino() as a
>fallback ? (expensive because they take a rwlock)

No, sock_i_uid also uses sk->sk_socket. What is interesting though is 
that sock_i_uid uses SOCK_INODE(sk->sk_socket)->i_uid, but xt_owner uses 
sk->sk_socket->file->f_cred->fsuid. Would you have an idea as to why 
that is?
Dave Howells (cced) did the last change on it.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html