linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* GPF in net sybsystem
@ 2021-05-05 17:02 Pavel Skripkin
  2021-05-06 22:09 ` Jakub Kicinski
  2021-05-07  0:40 ` Cong Wang
  0 siblings, 2 replies; 3+ messages in thread
From: Pavel Skripkin @ 2021-05-05 17:02 UTC (permalink / raw)
  To: ralf, davem, kuba; +Cc: netdev, linux-kernel

Hi, netdev developers!

I've spent some time debugging this bug
https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
and, I believe, I found the root case:

static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
		     bool kern)
{
....
	for (;;) {
		prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
		...
		if (!signal_pending(current)) {
			release_sock(sk);
			schedule();
			lock_sock(sk);
			continue;
		}
		...
	}
...
}

When calling process will be scheduled, another proccess can release
this socket and set sk->sk_wq to NULL. (In this case nr_release()
will call sock_orphan(sk)). In this case GPF will happen in
prepare_to_wait().

I came up with this patch, but im not an expect in netdev sybsystem and
im not sure about this one:

diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index 6d16e1ab1a8a..89ceddea48e8 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -803,6 +803,10 @@ static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
 			release_sock(sk);
 			schedule();
 			lock_sock(sk);
+			if (sock_flag(sk, SOCK_DEAD)) {
+				err = -ECONNABORTED;
+				goto out_release;
+			}
 			continue;
 		}
 		err = -ERESTARTSYS;

I look forward to hearing your perspective on this :)


BTW, I found similar code in:

1) net/ax25/af_ax25.c
2) net/rose/af_rose.c


I hope, this will help!

With regards,
Pavel Skripkin

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: GPF in net sybsystem
  2021-05-05 17:02 GPF in net sybsystem Pavel Skripkin
@ 2021-05-06 22:09 ` Jakub Kicinski
  2021-05-07  0:40 ` Cong Wang
  1 sibling, 0 replies; 3+ messages in thread
From: Jakub Kicinski @ 2021-05-06 22:09 UTC (permalink / raw)
  To: Pavel Skripkin; +Cc: ralf, davem, netdev, linux-kernel

On Wed, 5 May 2021 20:02:42 +0300 Pavel Skripkin wrote:
> Hi, netdev developers!
> 
> I've spent some time debugging this bug
> https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
> and, I believe, I found the root case:
> 
> static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
> 		     bool kern)
> {
> ....
> 	for (;;) {
> 		prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
> 		...
> 		if (!signal_pending(current)) {
> 			release_sock(sk);
> 			schedule();
> 			lock_sock(sk);
> 			continue;
> 		}
> 		...
> 	}
> ...
> }
> 
> When calling process will be scheduled, another proccess can release
> this socket and set sk->sk_wq to NULL. (In this case nr_release()
> will call sock_orphan(sk)). In this case GPF will happen in
> prepare_to_wait().

How does it get released midway through an accept call?
Is there a reference imbalance somewhere else in the code?

> I came up with this patch, but im not an expect in netdev sybsystem and
> im not sure about this one:
> 
> diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
> index 6d16e1ab1a8a..89ceddea48e8 100644
> --- a/net/netrom/af_netrom.c
> +++ b/net/netrom/af_netrom.c
> @@ -803,6 +803,10 @@ static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
>  			release_sock(sk);
>  			schedule();
>  			lock_sock(sk);
> +			if (sock_flag(sk, SOCK_DEAD)) {
> +				err = -ECONNABORTED;
> +				goto out_release;
> +			}
>  			continue;
>  		}
>  		err = -ERESTARTSYS;
> 
> I look forward to hearing your perspective on this :)
> 
> 
> BTW, I found similar code in:
> 
> 1) net/ax25/af_ax25.c
> 2) net/rose/af_rose.c
> 
> 
> I hope, this will help!
> 
> With regards,
> Pavel Skripkin


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: GPF in net sybsystem
  2021-05-05 17:02 GPF in net sybsystem Pavel Skripkin
  2021-05-06 22:09 ` Jakub Kicinski
@ 2021-05-07  0:40 ` Cong Wang
  1 sibling, 0 replies; 3+ messages in thread
From: Cong Wang @ 2021-05-07  0:40 UTC (permalink / raw)
  To: Pavel Skripkin
  Cc: Ralf Baechle, David Miller, Jakub Kicinski,
	Linux Kernel Network Developers, LKML

On Wed, May 5, 2021 at 10:36 AM Pavel Skripkin <paskripkin@gmail.com> wrote:
>
> Hi, netdev developers!
>
> I've spent some time debugging this bug
> https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
> and, I believe, I found the root case:
>
> static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
>                      bool kern)
> {
> ....
>         for (;;) {
>                 prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
>                 ...
>                 if (!signal_pending(current)) {
>                         release_sock(sk);
>                         schedule();
>                         lock_sock(sk);
>                         continue;
>                 }
>                 ...
>         }
> ...
> }
>
> When calling process will be scheduled, another proccess can release
> this socket and set sk->sk_wq to NULL. (In this case nr_release()
> will call sock_orphan(sk)). In this case GPF will happen in
> prepare_to_wait().

Are you sure?

How could another process release this socket when its fd is still
refcnt'ed? That is, accept() still does not return yet at the point of
schedule().

Also, the above pattern is pretty common in networking subsystem,
see sk_wait_event(), so how come it is only problematic for netrom?

Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-05-07  0:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-05 17:02 GPF in net sybsystem Pavel Skripkin
2021-05-06 22:09 ` Jakub Kicinski
2021-05-07  0:40 ` Cong Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).