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: <201101271317.01502.arnd@arndb.de>
Date:	Thu, 27 Jan 2011 13:17:01 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Andrew Hendry <andrew.hendry@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-x25@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 12/20] x25: remove the BKL

On Thursday 27 January 2011, Andrew Hendry wrote:
> Left it running and put about 3.0G through x.25, it was running fine
> until after about 20 hours.
> I was stopping the test programs and hit this.
> 
> Jan 27 20:18:34 jaunty kernel: [80403.945790] PGD 1d8b00067 PUD 1ddec3067 PMD 0

Is there no long above this about what problem was hit? There
is normally one saying things like "Bug: unable to handle ..."

Well, nevermind. It seems I could figure it out anyway:

> Jan 27 20:18:34 jaunty kernel: [80403.946083] RAX: 0000000000000080 RBX: ffff880228dbfd70 RCX: ffff880228dbfce4
> Jan 27 20:18:34 jaunty kernel: [80403.946096] RDX: 00000000fffffe00 RSI: 0000000000000000 RDI: ffff8801ba89f050
> Jan 27 20:18:34 jaunty kernel: [80403.946109] RBP: ffff880228dbfd18 R08: ffff88022aa91000 R09: 0000000000000000
> Jan 27 20:18:34 jaunty kernel: [80403.946482] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801ba89f000
> Jan 27 20:18:34 jaunty kernel: [80403.946495] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> ...
>
> If i have done it right, x25_sendmsg+0x1a7/0x530 is the skb_reserve
> which gets inlined here.
> (af_x25.c)
>         /* Build a packet */
>         SOCK_DEBUG(sk, "x25_sendmsg: sendto: building packet.\n");
> 
>         if ((msg->msg_flags & MSG_OOB) && len > 32)
>                 len = 32;
> 
>         size = len + X25_MAX_L2_LEN + X25_EXT_MIN_LEN;
> 
>         release_sock(sk);
>         skb = sock_alloc_send_skb(sk, size, noblock, &rc);
>         lock_sock(sk);
> 
>         X25_SKB_CB(skb)->flags = msg->msg_flags;


ok.

> objdump -dS show it at 2197 here.
> 
> static inline void skb_reserve(struct sk_buff *skb, int len)
> {
>         skb->data += len;
>         skb->tail += len;
>     2197:       41 83 87 b4 00 00 00    addl   $0x16,0xb4(%r15) <---
>     219e:       16
>     219f:       41 89 47 28             mov    %eax,0x28(%r15)
>     21a3:       49 8b 87 c8 00 00 00    mov    0xc8(%r15),%rax
>     21aa:       48 83 c0 16             add    $0x16,%rax
>         skb_reserve(skb, X25_MAX_L2_LEN + X25_EXT_MIN_LEN);
> 
> But im not sure where to go from there...
 
It's pretty clear that %r15 is the skb in this, and from the registers in the dump,
you can see that it's NULL. skb has just been returned from sock_alloc_send_skb,
which means that this function failed.

And indeed:

> > @@ -1148,9 +1140,10 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
> >
> >        size = len + X25_MAX_L2_LEN + X25_EXT_MIN_LEN;
> >
> > +       release_sock(sk);
> >        skb = sock_alloc_send_skb(sk, size, noblock, &rc);
> > -       if (!skb)
> > -               goto out;
> > +       lock_sock(sk);
> > +
> >        X25_SKB_CB(skb)->flags = msg->msg_flags;

I accidentally removed the error handling in my patch. No idea how that
happened, it certainly wasn't intentional. Thanks a lot for the thorough
testing and the detailed bug report!

I'll follow up with a fixed patch that puts the error path back in.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ