| Message ID | 20110420033001.GA32635@redhat.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Dave Jones <davej@redhat.com> Date: Tue, 19 Apr 2011 23:30:01 -0400 > We can get here with a NULL socket argument passed from userspace, > so we need to handle it accordingly. > > Signed-off-by: Dave Jones <davej@redhat.com> Applied and queued up for -stable, thanks Dave. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 19, 2011 at 08:37:20PM -0700, David Miller wrote: > From: Dave Jones <davej@redhat.com> > Date: Tue, 19 Apr 2011 23:30:01 -0400 > > > We can get here with a NULL socket argument passed from userspace, > > so we need to handle it accordingly. > > > > Signed-off-by: Dave Jones <davej@redhat.com> > > Applied and queued up for -stable, thanks Dave. Out of curiousity, while I was asleep it occured to me.. is it ever valid for a ->release to get passed a NULL socket->sk ? I'm wondering if we can't do this check a layer up in sock_release, in case future protocols reintroduce the same bug. From a quick look, almost every protocol has this check in its ->release. Though it seems some do something different instead of using socket->sk, so it would be a pointless check for some of the lesser used ones. thoughts? Dave -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dave Jones <davej@redhat.com> Date: Wed, 20 Apr 2011 12:03:50 -0400 > On Tue, Apr 19, 2011 at 08:37:20PM -0700, David Miller wrote: > > From: Dave Jones <davej@redhat.com> > > Date: Tue, 19 Apr 2011 23:30:01 -0400 > > > > > We can get here with a NULL socket argument passed from userspace, > > > so we need to handle it accordingly. > > > > > > Signed-off-by: Dave Jones <davej@redhat.com> > > > > Applied and queued up for -stable, thanks Dave. > > Out of curiousity, while I was asleep it occured to me.. is it ever valid > for a ->release to get passed a NULL socket->sk ? Yes, it happens all the time. If accept() fails mid-stream, we'll have an 'sk' that hasn't been hooked up to ->socket yet, but we still have to release the 'sk' in the error handling. See also commit c100c8f4c3c6f2a407bdbaaad2c4f1062e6a473a, which fixes a bug triggered via the same code path. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/can/bcm.c b/net/can/bcm.c index 57b1aed..8a6a05e 100644 --- a/net/can/bcm.c +++ b/net/can/bcm.c @@ -1427,9 +1427,14 @@ static int bcm_init(struct sock *sk) static int bcm_release(struct socket *sock) { struct sock *sk = sock->sk; - struct bcm_sock *bo = bcm_sk(sk); + struct bcm_sock *bo; struct bcm_op *op, *next; + if (sk == NULL) + return 0; + + bo = bcm_sk(sk); + /* remove bcm_ops, timer, rx_unregister(), etc. */ unregister_netdevice_notifier(&bo->notifier);
We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by: Dave Jones <davej@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html