netdev - Re: race in skb_splice

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]

Date:	Tue, 27 May 2008 15:53:49 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org
Subject: Re: race in skb_splice_bits?

On Tuesday 27 May 2008, Evgeniy Polyakov wrote:

> > > However, from Octavian's later mail it seems we can't let the skb go
> > > away at all.  So some wider changes seem to be required.
> >
> > Yes, I misread the original message.
> >
> > Octavian, could you please decode where bug occured via gdb:
> > gdb
> > $ l *(skb_splice_bits+0x130)
>
> It is lock_sock()?
>

Yes it is lock_sock(). The crash in lock_sock() occurs with the following 
sequence:

release_sock(__skb->sk);
ret = splice_to_pipe(pipe, &spd);
lock_sock(__skb->sk);

0x8010c94c is in skb_splice_bits (include/net/sock.h:837).
832
833     extern void lock_sock_nested(struct sock *sk, int subclass);
834
835     static inline void lock_sock(struct sock *sk)
836     {
837             lock_sock_nested(sk, 0);
838     }
839
840     extern void release_sock(struct sock *sk);
841

> And also please show what
> tcp_read_sock+0x108
> tcp_read_sock+0x138
>
> are.

This crash occurs with the following sequence:

struct sock *sk= __skb->sk;

release_sock(sk);
ret = splice_to_pipe(pipe, &spd);
lock_sock(sk);

0x8014d090 is in tcp_read_sock (net/ipv4/tcp.c:1225).
1220                            used = recv_actor(desc, skb, offset, len);
1221                            if (used < 0) {
1222                                    if (!copied)
1223                                            copied = used;
1224                                    break;
1225                            } else if (used <= len) {
1226                                    seq += used;
1227                                    copied += used;
1228                                    offset += used;
1229                            }

> And do you have a test case for that? 

Yes. I've attached my test program which triggers both crashes. To improve the 
reproducibility rate you need to use a relatively high buffer for splice (I 
used 16384) and a small MTU (I used 128). This will make the 1st splice on 
the receive side block (due to not enough PIPE_BUFFERS it seems), and will 
give plenty of time to the race condition to manifest itself. When you 
interrupt the program, the system will crash.

Thanks,
tavi

View attachment "splice.c" of type "text/x-csrc" (7933 bytes)