Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

[Eric Biggers]

On Thu, Sep 27, 2018 at 11:35:39PM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
> 
> On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers  wrote:
> > Why is Herbert Xu's existing crypto tree being circumvented, especially for
> > future patches (the initial merge isn't quite as important as that's a 
> > one-time
> > event)?  I like being able to check out cryptodev to test upcoming crypto
> > patches.  And currently, changes to APIs, algorithms, tests, and 
> > implementations
> > all go through cryptodev, which is convenient for crypto developers.
> >
> > Apparently, you're proposing that someone adding a new algorithm will now 
> > have
> > to submit the API portion to one maintainer (Herbert Xu) and the 
> > implementation
> > portion to another maintainer (you), and they'll go through separate git 
> > trees.
> > That's inconvenient for developers, and it seems that in practice you and
> > Herbert will be stepping on each other's toes a lot.
> >
> > Can you please reach some kind of sane agreement with Herbert so that the
> > development process isn't fractured into two?  Perhaps you could review 
> > patches,
> > but Herbert could still apply them?
> 
> I think you're overthinking it a bit. Zinc will have a few software
> implementations of primitives that are useful in cases where it's nice to call
> the primitive directly. Think: various usages of sha2, siphash, the wireguard
> suite (what this patchset includes), other things in lib/, etc. In so much as
> this winds up duplicating things within the crypto API, I'll work with Herbert
> to build one on top of the other -- as I've done in the two commits in this
> series. But beyond that, think of the two initiatives as orthogonal. I'm
> working on curating a few primitives that are maximally useful throughout
> the kernel for various uses, and doing so in a way that I think brings
> about a certain quality. Meanwhile the crypto API is amassing a huge
> collection of primitives for some things, and that will continue to exist,
> and Herbert will continue to maintain that. I expect for the crossover
> to be fairly isolated and manageable, without too much foreseeable tree-
> conflicts and such. Therefore, Samuel Neves and I plan to maintain the
> codebase we've spent quite some time writing, and maintain our own tree for
> it, which we'll be submitting through Greg. In other words, this is not
> a matter of "circumvention" or "stepping on toes", but rather separate
> efforts. I'm quite certain to the extent they overlap we'll be able to work
> out fairly easily.
> 
> Either way, I'll take your suggestion and reach out to Herbert, since at
> least a discussion between the two of us sounds like it could be productive.

So, Zinc will simultaneously replace the current crypto implementations, *and*
be "orthogonal" and "separate" from all the crypto code currently maintained by
Herbert?  You can't have your cake and eat it too...

I'm still concerned you're splitting the community in two.  It will be unclear
where new algorithms and implementations should go.  Some people will choose
Herbert and the current crypto API and conventions, and some people will choose
you and Zinc...  I still don't see clear guidelines for what will go where.  And
yes, you and Herbert will step on each others' toes and duplicate stuff, as the
efforts are *not* separate, as you've even argued yourself.

Please reach out to Herbert to find a sane solution, ideally one that involves
having a single git tree for crypto development and allows people to continue
crypto development without choosing "sides".

> 
> > I'm also wondering about the criteria for making additions and changes to
> > "Zinc".  You mentioned before that one of the "advantages" of Zinc is that 
> > it
> > doesn't include "cipher modes from 90s cryptographers" -- what does that 
> > mean
> > exactly?  You've also indicated before that you don't want people modifying 
> > the
> > Poly1305 implementations as they are too error-prone.  Useful contributions
> > could be blocked or discouraged in the future. Can you please elaborate on
> > your criteria for contributions to Zinc?
> >
> > Also, will you allow algorithms that aren't up to modern security standards 
> > but
> > are needed for compatibility reasons, e.g. MD5, SHA-1, and DES?  There are
> > existing standards, APIs, and data formats that use these "legacy" 
> > algorithms;
> > so implementations of them are often still needed, whether we like it or 
> > not.
> >
> > And does it matter who designed the algorithms, e.g. do algorithms from 
> > Daniel
&g

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

[Eric Biggers]

On Tue, Sep 25, 2018 at 04:55:59PM +0200, Jason A. Donenfeld wrote:
> 
> It is intended that this entire patch series enter the kernel through
> DaveM's net-next tree. Subsequently, WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
> 

Why is Herbert Xu's existing crypto tree being circumvented, especially for
future patches (the initial merge isn't quite as important as that's a one-time
event)?  I like being able to check out cryptodev to test upcoming crypto
patches.  And currently, changes to APIs, algorithms, tests, and implementations
all go through cryptodev, which is convenient for crypto developers.

Apparently, you're proposing that someone adding a new algorithm will now have
to submit the API portion to one maintainer (Herbert Xu) and the implementation
portion to another maintainer (you), and they'll go through separate git trees.
That's inconvenient for developers, and it seems that in practice you and
Herbert will be stepping on each other's toes a lot.

Can you please reach some kind of sane agreement with Herbert so that the
development process isn't fractured into two?  Perhaps you could review patches,
but Herbert could still apply them?

I'm also wondering about the criteria for making additions and changes to
"Zinc".  You mentioned before that one of the "advantages" of Zinc is that it
doesn't include "cipher modes from 90s cryptographers" -- what does that mean
exactly?  You've also indicated before that you don't want people modifying the
Poly1305 implementations as they are too error-prone.  Yet apparently it's fine
to change them yourself, e.g. when you added the part that converts the
accumulator from base 26 to base 32.  I worry there may be double standards
here, and useful contributions could be blocked or discouraged in the future.
Can you please elaborate on your criteria for contributions to Zinc?

Also, will you allow algorithms that aren't up to modern security standards but
are needed for compatibility reasons, e.g. MD5, SHA-1, and DES?  There are
existing standards, APIs, and data formats that use these "legacy" algorithms;
so implementations of them are often still needed, whether we like it or not.

And does it matter who designed the algorithms, e.g. do algorithms from Daniel
Bernstein get effectively a free pass, while algorithms from certain countries,
governments, or organizations are not allowed?  E.g. wireless driver developers
may need the SM4 block cipher (which is now supported by the crypto API) as it's
specified in a Chinese wireless standard.  Will you allow SM4 in Zinc?  Or will
people have to submit some algorithms to Herbert and some to you due to
disagreements about what algorithms should be included?

- Eric

[PATCH net v2] KEYS: DNS: fix parsing multiple options

[Eric Biggers]

From: Eric Biggers 

My recent fix for dns_resolver_preparse() printing very long strings was
incomplete, as shown by syzbot which still managed to hit the
WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:

precision 50001 too large
WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0

The bug this time isn't just a printing bug, but also a logical error
when multiple options ("#"-separated strings) are given in the key
payload.  Specifically, when separating an option string into name and
value, if there is no value then the name is incorrectly considered to
end at the end of the key payload, rather than the end of the current
option.  This bypasses validation of the option length, and also means
that specifying multiple options is broken -- which presumably has gone
unnoticed as there is currently only one valid option anyway.

A similar problem also applied to option values, as the kstrtoul() when
parsing the "dnserror" option will read past the end of the current
option and into the next option.

Fix these bugs by correctly computing the length of the option name and
by copying the option value, null-terminated, into a temporary buffer.

Reproducer for the WARN_ONCE() that syzbot hit:

perl -e 'print "#A#", "\0" x 5' | keyctl padd dns_resolver desc @s

Reproducer for "dnserror" option being parsed incorrectly (expected
behavior is to fail when seeing the unknown option "foo", actual
behavior was to read the dnserror value as "1#foo" and fail there):

perl -e 'print "#dnserror=1#foo\0"' | keyctl padd dns_resolver desc @s

Reported-by: syzbot 
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Signed-off-by: Eric Biggers 
---

Changed since v1:
- Also fix parsing the option values, not just option names.

 net/dns_resolver/dns_key.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 40c851693f77..0c9478b91fa5 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -86,35 +86,39 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
opt++;
kdebug("options: '%s'", opt);
do {
+   int opt_len, opt_nlen;
const char *eq;
-   int opt_len, opt_nlen, opt_vlen, tmp;
+   char optval[128];
 
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
-   if (opt_len <= 0 || opt_len > 128) {
+   if (opt_len <= 0 || opt_len > sizeof(optval)) {
pr_warn_ratelimited("Invalid option length (%d) 
for dns_resolver key\n",
opt_len);
return -EINVAL;
}
 
-   eq = memchr(opt, '=', opt_len) ?: end;
-   opt_nlen = eq - opt;
-   eq++;
-   opt_vlen = next_opt - eq; /* will be -1 if no value */
+   eq = memchr(opt, '=', opt_len);
+   if (eq) {
+   opt_nlen = eq - opt;
+   eq++;
+   memcpy(optval, eq, next_opt - eq);
+   optval[next_opt - eq] = '\0';
+   } else {
+   opt_nlen = opt_len;
+   optval[0] = '\0';
+   }
 
-   tmp = opt_vlen >= 0 ? opt_vlen : 0;
-   kdebug("option '%*.*s' val '%*.*s'",
-  opt_nlen, opt_nlen, opt, tmp, tmp, eq);
+   kdebug("option '%*.*s' val '%s'",
+  opt_nlen, opt_nlen, opt, optval);
 
/* see if it's an error number representing a DNS error
 * that's to be recorded as the result in this key */
if (opt_nlen == sizeof(DNS_ERRORNO_OPTION) - 1 &&
memcmp(opt, DNS_ERRORNO_OPTION, opt_nlen) == 0) {
kdebug("dns error number option");
-   if (opt_vlen <= 0)
-   goto bad_option_value;
 
-   ret = kstrtoul(eq, 10, );
+   ret = kstrtoul(optval, 10, );
if (ret < 0)
goto bad_option_value;
 
-- 
2.18.0.203.gfac676dfb9-goog

Re: [PATCH net] KEYS: DNS: fix parsing multiple options

[Eric Biggers]

On Thu, Jun 14, 2018 at 05:14:30PM +0100, David Howells wrote:
> The fix seems to work, but the use of kstrtoul():
> 
>   ret = kstrtoul(eq, 10, );
> 
> is incorrect since the buffer can't been modified to block out the next
> argument if there is one, so the following fails:
> 
>   perl -e 'print "#dnserror=1#", "\x00" x 1' |
>   keyctl padd dns_resolver desc @s
> 
> (Note this is preexisting and nothing to do with your patch).
> 
> I'm not sure how best to handle this.
> 
> Anyway, Dave, can you take Eric's patch into the net tree with:
> 
>   Acked-by: David Howells 
> 
> David

It could be handled by copying the option value to a temporary buffer.
Anyway, that can be a separate fix...

David (Miller), are you planning to take this through -net?

Thanks!

- Eric

Re: [PATCH net] KEYS: DNS: fix parsing multiple options

[Eric Biggers]

Hi Simon,

On Mon, Jun 11, 2018 at 11:40:23AM +0200, Simon Horman wrote:
> On Fri, Jun 08, 2018 at 09:20:37AM -0700, Eric Biggers wrote:
> > From: Eric Biggers 
> > 
> > My recent fix for dns_resolver_preparse() printing very long strings was
> > incomplete, as shown by syzbot which still managed to hit the
> > WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
> > 
> > precision 50001 too large
> > WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
> > 
> > The bug this time isn't just a printing bug, but also a logical error
> > when multiple options ("#"-separated strings) are given in the key
> > payload.  Specifically, when separating an option string into name and
> > value, if there is no value then the name is incorrectly considered to
> > end at the end of the key payload, rather than the end of the current
> > option.  This bypasses validation of the option length, and also means
> > that specifying multiple options is broken -- which presumably has gone
> > unnoticed as there is currently only one valid option anyway.
> > 
> > Fix it by correctly calculating the length of the option name.
> > 
> > Reproducer:
> > 
> > perl -e 'print "#A#", "\x00" x 50000' | keyctl padd dns_resolver desc @s
> > 
> > Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that 
> > to be cached [ver #2]")
> > Signed-off-by: Eric Biggers 
> > ---
> >  net/dns_resolver/dns_key.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
> > index 40c851693f77e..d448823d4d2ed 100644
> > --- a/net/dns_resolver/dns_key.c
> > +++ b/net/dns_resolver/dns_key.c
> > @@ -97,7 +97,7 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
> > return -EINVAL;
> > }
> >  
> > -   eq = memchr(opt, '=', opt_len) ?: end;
> > +   eq = memchr(opt, '=', opt_len) ?: next_opt;
> > opt_nlen = eq - opt;
> > eq++;
> 
> It seems risky to advance eq++ in the case there the value is empty.
> Its not not pointing to the value but it may be accessed twice further on
> in this loop.
> 

Sure, that's a separate existing issue though, and it must be checked that the
value is present before using it anyway, which the code already does, so it's
not a "real" bug.  I think I'll keep this patch simple and leave that part as-is
for now.

Eric

[PATCH net] KEYS: DNS: fix parsing multiple options

[Eric Biggers]

From: Eric Biggers 

My recent fix for dns_resolver_preparse() printing very long strings was
incomplete, as shown by syzbot which still managed to hit the
WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:

precision 50001 too large
WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0

The bug this time isn't just a printing bug, but also a logical error
when multiple options ("#"-separated strings) are given in the key
payload.  Specifically, when separating an option string into name and
value, if there is no value then the name is incorrectly considered to
end at the end of the key payload, rather than the end of the current
option.  This bypasses validation of the option length, and also means
that specifying multiple options is broken -- which presumably has gone
unnoticed as there is currently only one valid option anyway.

Fix it by correctly calculating the length of the option name.

Reproducer:

perl -e 'print "#A#", "\x00" x 5' | keyctl padd dns_resolver desc @s

Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Signed-off-by: Eric Biggers 
---
 net/dns_resolver/dns_key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 40c851693f77e..d448823d4d2ed 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -97,7 +97,7 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
return -EINVAL;
}
 
-   eq = memchr(opt, '=', opt_len) ?: end;
+   eq = memchr(opt, '=', opt_len) ?: next_opt;
opt_nlen = eq - opt;
eq++;
opt_vlen = next_opt - eq; /* will be -1 if no value */
-- 
2.18.0.rc1.242.g61856ae69a-goog

[PATCH v2] ppp: remove the PPPIOCDETACH ioctl

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file
before f_count has reached 0, which is fundamentally a bad idea.  It
does check 'f_count < 2', which excludes concurrent operations on the
file since they would only be possible with a shared fd table, in which
case each fdget() would take a file reference.  However, it fails to
account for the fact that even with 'f_count == 1' the file can still be
linked into epoll instances.  As reported by syzbot, this can trivially
be used to cause a use-after-free.

Yet, the only known user of PPPIOCDETACH is pppd versions older than
ppp-2.4.2, which was released almost 15 years ago (November 2003).
Also, PPPIOCDETACH apparently stopped working reliably at around the
same time, when the f_count check was added to the kernel, e.g. see
https://lkml.org/lkml/2002/12/31/83.  Also, the current 'f_count < 2'
check makes PPPIOCDETACH only work in single-threaded applications; it
always fails if called from a multithreaded application.

All pppd versions released in the last 15 years just close() the file
descriptor instead.

Therefore, instead of hacking around this bug by exporting epoll
internals to modules, and probably missing other related bugs, just
remove the PPPIOCDETACH ioctl and see if anyone actually notices.  Leave
a stub in place that prints a one-time warning and returns EINVAL.

Reported-by: syzbot+16363c99d4134717c...@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers <ebigg...@google.com>
---

v2: leave a stub in place, rather than removing the ioctl completely.

 Documentation/networking/ppp_generic.txt |  6 --
 drivers/net/ppp/ppp_generic.c| 27 +---
 include/uapi/linux/ppp-ioctl.h   |  2 +-
 3 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/Documentation/networking/ppp_generic.txt 
b/Documentation/networking/ppp_generic.txt
index 091d20273dcb..61daf4b39600 100644
--- a/Documentation/networking/ppp_generic.txt
+++ b/Documentation/networking/ppp_generic.txt
@@ -300,12 +300,6 @@ unattached instance are:
 The ioctl calls available on an instance of /dev/ppp attached to a
 channel are:
 
-* PPPIOCDETACH detaches the instance from the channel.  This ioctl is
-  deprecated since the same effect can be achieved by closing the
-  instance.  In order to prevent possible races this ioctl will fail
-  with an EINVAL error if more than one file descriptor refers to this
-  instance (i.e. as a result of dup(), dup2() or fork()).
-
 * PPPIOCCONNECT connects this channel to a PPP interface.  The
   argument should point to an int containing the interface unit
   number.  It will return an EINVAL error if the channel is already
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index dc7c7ec43202..02ad03a2fab7 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -605,30 +605,13 @@ static long ppp_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 
if (cmd == PPPIOCDETACH) {
/*
-* We have to be careful here... if the file descriptor
-* has been dup'd, we could have another process in the
-* middle of a poll using the same file *, so we had
-* better not free the interface data structures -
-* instead we fail the ioctl.  Even in this case, we
-* shut down the interface if we are the owner of it.
-* Actually, we should get rid of PPPIOCDETACH, userland
-* (i.e. pppd) could achieve the same effect by closing
-* this fd and reopening /dev/ppp.
+* PPPIOCDETACH is no longer supported as it was heavily broken,
+* and is only known to have been used by pppd older than
+* ppp-2.4.2 (released November 2003).
 */
+   pr_warn_once("%s (%d) used obsolete PPPIOCDETACH ioctl\n",
+current->comm, current->pid);
err = -EINVAL;
-   if (pf->kind == INTERFACE) {
-   ppp = PF_TO_PPP(pf);
-   rtnl_lock();
-   if (file == ppp->owner)
-   unregister_netdevice(ppp->dev);
-   rtnl_unlock();
-   }
-   if (atomic_long_read(>f_count) < 2) {
-   ppp_release(NULL, file);
-   err = 0;
-   } else
-   pr_warn("PPPIOCDETACH file->f_count=%ld\n",
-   atomic_long_read(>f_count));
goto out;
}
 
diff --git a/include/uapi/linux/ppp-ioctl.h b/include/uapi/linux/ppp-ioctl.h
index b19a9c249b15..784c2e3e572e 100644
--- a/include/u

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

[Eric Biggers]

On Wed, May 23, 2018 at 11:56:36AM -0400, David Miller wrote:
> From: Guillaume Nault 
> Date: Wed, 23 May 2018 15:57:08 +0200
> 
> > I'd rather add
> > +   if (cmd == PPPIOCDETACH) {
> > +   err = -EINVAL;
> > +   goto out;
> > +   }
> > 
> > Making PPPIOCDETACH unknown to ppp_generic means that the ioctl would
> > be handled by the underlying channel when pf->kind == CHANNEL (see the
> > chan->ops->ioctl() call further down). That shouldn't be a problem per
> > se, but even though PPPIOCDETACH is unsupported, I feel that it should
> > remain a ppp_generic thing. I don't really want its value to be reused
> > for other purposes in the future or have different behaviour depending
> > on the underlying channel.
> > 
> > Also PPPIOCDETACH can already fail with -EINVAL. Therefore, if ever
> > there really were programs out there using this call, they'd already
> > have to handle this case. Unconditionally returning -EINVAL would
> > further minimise possibilities for breakage.
> 
> I agree.

Okay, I'll do that and leave the ioctl number reserved.
I will add a pr_warn_once() too.

Thanks,

- Eric

[PATCH] ppp: remove the PPPIOCDETACH ioctl

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file
before f_count has reached 0, which is fundamentally a bad idea.  It
does check 'f_count < 2', which excludes concurrent operations on the
file since they would only be possible with a shared fd table, in which
case each fdget() would take a file reference.  However, it fails to
account for the fact that even with 'f_count == 1' the file can still be
linked into epoll instances.  As reported by syzbot, this can trivially
be used to cause a use-after-free.

Yet, the only known user of PPPIOCDETACH is pppd versions older than
ppp-2.4.2, which was released almost 15 years ago (November 2003).
Also, PPPIOCDETACH apparently stopped working reliably at around the
same time, when the f_count check was added to the kernel, e.g. see
https://lkml.org/lkml/2002/12/31/83.  Also, the current 'f_count < 2'
check makes PPPIOCDETACH only work in single-threaded applications; it
always fails if called from a multithreaded application.

All pppd versions released in the last 15 years just close() the file
descriptor instead.

Therefore, instead of hacking around this bug by exporting epoll
internals to modules, and probably missing other related bugs, just
remove the PPPIOCDETACH ioctl and see if anyone actually notices.

Reported-by: syzbot+16363c99d4134717c...@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 Documentation/networking/ppp_generic.txt |  6 -
 drivers/net/ppp/ppp_generic.c| 29 
 fs/compat_ioctl.c|  1 -
 include/uapi/linux/ppp-ioctl.h   |  1 -
 4 files changed, 37 deletions(-)

diff --git a/Documentation/networking/ppp_generic.txt 
b/Documentation/networking/ppp_generic.txt
index 091d20273dcb..61daf4b39600 100644
--- a/Documentation/networking/ppp_generic.txt
+++ b/Documentation/networking/ppp_generic.txt
@@ -300,12 +300,6 @@ unattached instance are:
 The ioctl calls available on an instance of /dev/ppp attached to a
 channel are:
 
-* PPPIOCDETACH detaches the instance from the channel.  This ioctl is
-  deprecated since the same effect can be achieved by closing the
-  instance.  In order to prevent possible races this ioctl will fail
-  with an EINVAL error if more than one file descriptor refers to this
-  instance (i.e. as a result of dup(), dup2() or fork()).
-
 * PPPIOCCONNECT connects this channel to a PPP interface.  The
   argument should point to an int containing the interface unit
   number.  It will return an EINVAL error if the channel is already
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index dc7c7ec43202..dce8812fe802 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -603,35 +603,6 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
goto out;
}
 
-   if (cmd == PPPIOCDETACH) {
-   /*
-* We have to be careful here... if the file descriptor
-* has been dup'd, we could have another process in the
-* middle of a poll using the same file *, so we had
-* better not free the interface data structures -
-* instead we fail the ioctl.  Even in this case, we
-* shut down the interface if we are the owner of it.
-* Actually, we should get rid of PPPIOCDETACH, userland
-* (i.e. pppd) could achieve the same effect by closing
-* this fd and reopening /dev/ppp.
-*/
-   err = -EINVAL;
-   if (pf->kind == INTERFACE) {
-   ppp = PF_TO_PPP(pf);
-   rtnl_lock();
-   if (file == ppp->owner)
-   unregister_netdevice(ppp->dev);
-   rtnl_unlock();
-   }
-   if (atomic_long_read(>f_count) < 2) {
-   ppp_release(NULL, file);
-   err = 0;
-   } else
-   pr_warn("PPPIOCDETACH file->f_count=%ld\n",
-   atomic_long_read(>f_count));
-   goto out;
-   }
-
if (pf->kind == CHANNEL) {
struct channel *pch;
struct ppp_channel *chan;
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index ef80085ed564..8285b570d635 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -917,7 +917,6 @@ COMPATIBLE_IOCTL(PPPIOCSDEBUG)
 /* PPPIOCGIDLE is translated */
 COMPATIBLE_IOCTL(PPPIOCNEWUNIT)
 COMPATIBLE_IOCTL(PPPIOCATTACH)
-COMPATIBLE_IOCTL(PPPIOCDETACH)
 COMPATIBLE_IOCTL(PPPIOCSMRRU)
 COMPATIBLE_IOCTL(PPPIOCCONNECT)
 COMPATIBLE_IOCTL(PPPIOCDISCONN)
diff --git a/include/uapi/linux/ppp-i

Re: KASAN: use-after-free Read in remove_wait_queue (2)

[Eric Biggers]

On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote:
> On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote:
> > [+ppp list and maintainer]
> > 
> > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's 
> > easily
> > reproducible, see program below.  The bug is that the PPPIOCDETACH ioctl 
> > doesn't
> > consider that the file can still be attached to epoll instances even when
> > ->f_count == 1.
> 
> Right. What would it take to remove the file for the epoll instances?
> Sorry for the naive question, but I'm not familiar with VFS and didn't
> find a helper function we could call.
> 

There is eventpoll_release_file(), but it's not exported to modules.  It might
work to call it, but it seems like a hack.

> > Also, the reproducer doesn't test this but I think ppp_poll(),
> > ppp_read(), and ppp_write() can all race with PPPIOCDETACH, causing
> > use-after-frees as well.
> 
> I also believe so. ppp_release() resets ->private_data, and even though
> functions like ppp_read() test ->private_data before executing, there's
> no synchronisation mechanism to ensure that the update is visible
> before the unit or channel is destroyed. Is that the kind of race you
> had in mind?

Yes, though after looking into it more I *think* these additional races aren't
actually possible, due to the 'f_count < 2' check.  These races could only
happen with a shared fd table, but in that case fdget() would increment f_count
for the duration of each operation, resulting in 'f_count >= 2' if both ioctl()
and something else is running on the same file concurrently.

Note that this also means PPPIOCDETACH doesn't work at all if called from a
multithreaded application...

> 
> > Any chance that PPPIOCDETACH can simply be removed,
> > given that it's apparently been "deprecated" for 16 years?
> > Does anyone use it?
> 
> The only users I'm aware of are pppd versions older than ppp-2.4.2
> (released in November 2003). But even at that time, there were issues
> with PPPIOCDETACH as pppd didn't seem to react properly when this call
> failed. An Internet search on the "PPPIOCDETACH file->f_count=" kernel
> log string, or on the "Couldn't release PPP unit: Invalid argument"
> error message of pppd, returns several related bug reports.
> 
> Originally, PPPIOCDETACH never failed, but testing ->f_count was
> later introduced to fix crashes when the file descriptor had been
> duplicated. It seems that this was motivated by polling issues too.
> 
> Long story short, it looks like PPPIOCDETACH never has worked well
> and we have at least two more bugs to fix. Given how it has proven
> fragile, I wouldn't be surprised if there were even more lurking
> around. I'd say that it's probably safer to drop it than to add more
> workarounds and playing wack-a-mole with those bugs.

IMO, if we can get away with removing it without any users noticing, that would
be much better than trying to fix it with a VFS-level hack, and probably missing
some cases.  I'll send a patch to get things started...

- Eric

Re: KASAN: use-after-free Read in remove_wait_queue (2)

[Eric Biggers]

[+ppp list and maintainer]

On Wed, Feb 28, 2018 at 08:59:02AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> f3afe530d644488a074291da04a69a296ab63046 (Tue Feb 27 22:02:39 2018 +)
> Merge branch 'fixes-v4.16-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
> 
> So far this crash happened 3 times on upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+16363c99d4134717c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1519800493.311:7): avc:  denied  { map } for
> pid=4238 comm="syzkaller305740" path="/root/syzkaller305740266" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: use-after-free in __lock_acquire+0x3d4d/0x3e00
> kernel/locking/lockdep.c:3310
> Read of size 8 at addr 8801afa039c0 by task syzkaller305740/4238
> 
> CPU: 1 PID: 4238 Comm: syzkaller305740 Not tainted 4.16.0-rc3+ #332
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x24d lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  __lock_acquire+0x3d4d/0x3e00 kernel/locking/lockdep.c:3310
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>  remove_wait_queue+0x81/0x350 kernel/sched/wait.c:50
>  ep_remove_wait_queue fs/eventpoll.c:596 [inline]
>  ep_unregister_pollwait.isra.7+0x18c/0x590 fs/eventpoll.c:614
>  ep_free+0x13f/0x320 fs/eventpoll.c:832
>  ep_eventpoll_release+0x44/0x60 fs/eventpoll.c:864
>  __fput+0x327/0x7e0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:243
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  SYSC_exit_group kernel/exit.c:979 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:977
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43e958
> RSP: 002b:7ffe63a11468 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX:  RCX: 0043e958
> RDX:  RSI: 003c RDI: 
> RBP: 004be300 R08: 00e7 R09: ffd0
> R10: 004002c8 R11: 0246 R12: 0001
> R13: 006cc160 R14:  R15: 
> 
> Allocated by task 4238:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  __do_kmalloc_node mm/slab.c:3669 [inline]
>  __kmalloc_node+0x47/0x70 mm/slab.c:3676
>  kmalloc_node include/linux/slab.h:554 [inline]
>  kvmalloc_node+0x99/0xd0 mm/util.c:419
>  kvmalloc include/linux/mm.h:541 [inline]
>  kvzalloc include/linux/mm.h:549 [inline]
>  alloc_netdev_mqs+0x16d/0xfb0 net/core/dev.c:8299
>  ppp_create_interface drivers/net/ppp/ppp_generic.c:3018 [inline]
>  ppp_unattached_ioctl drivers/net/ppp/ppp_generic.c:866 [inline]
>  ppp_ioctl+0x1715/0x2a50 drivers/net/ppp/ppp_generic.c:602
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> 
> Freed by task 4238:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd9/0x260 mm/slab.c:3800
>  kvfree+0x36/0x60 mm/util.c:438
>  netdev_freemem+0x4c/0x60 net/core/dev.c:8253
>  netdev_release+0x10a/0x160 net/core/net-sysfs.c:1502
>  device_release+0x7c/0x210 drivers/base/core.c:814
>  kobject_cleanup lib/kobject.c:646 [inline]
>  kobject_release lib/kobject.c:675 [inline]
>  kref_put include/linux/kref.h:70 [inline]
>  kobject_put+0x14c/0x250 lib/kobject.c:692
>  put_device+0x20/0x30 drivers/base/core.c:1931
>  free_netdev+0x2f5/0x400 net/core/dev.c:8410
>  

Re: WARNING: suspicious RCU usage in tipc_bearer_find

[Eric Biggers]

On Fri, Feb 09, 2018 at 12:00:01PM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on net-next commit
> 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +)
> Merge tag 'usercopy-v4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
> 
> So far this crash happened 13 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b743957adcee51f5e...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed.
> 
> 
> audit: type=1400 audit(1518206230.395:8): avc:  denied  { create } for
> pid=4164 comm="syzkaller756462"
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tclass=netlink_generic_socket permissive=1
> =
> audit: type=1400 audit(1518206230.396:9): avc:  denied  { write } for
> pid=4164 comm="syzkaller756462"
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tclass=netlink_generic_socket permissive=1
> WARNING: suspicious RCU usage
> 4.15.0+ #221 Not tainted
> -
> net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by syzkaller756462/4164:
>  #0:  (cb_lock){}, at: [<3bb01113>] genl_rcv+0x19/0x40
> net/netlink/genetlink.c:634
>  #1:  (genl_mutex){+.+.}, at: [<2e321e71>] genl_lock
> net/netlink/genetlink.c:33 [inline]
>  #1:  (genl_mutex){+.+.}, at: [<2e321e71>] genl_rcv_msg+0x115/0x140
> net/netlink/genetlink.c:622
> 
> stack backtrace:
> CPU: 0 PID: 4164 Comm: syzkaller756462 Not tainted 4.15.0+ #221
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592
>  tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
>  tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
>  __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
>  tipc_nl_compat_doit+0x15b/0x670 net/tipc/netlink_compat.c:335
>  tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
>  tipc_nl_compat_recv+0x1135/0x18f0 net/tipc/netlink_compat.c:1201
>  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
>  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
>  netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2442
>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2080
>  SYSC_sendmsg net/socket.c:2091 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2087
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x43fd69
> RSP: 002b:7fff09979378 EFLAGS: 0203 ORIG_RAX: 002e
> RAX: ffda RBX: 004002c8 RCX: 0043fd69
> RDX:  RSI: 20003000 RDI: 0003
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0203 R12: 00401690
> R13: 00401720 R14:  R15: 000
> 

This was fixed by commit ed4ffdfec26df:

#syz fix: tipc: Fix missing RTNL lock protection during setting link properties

- Eric

[PATCH] net/smc: check for missing nlattrs in SMC_PNETID messages

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

It's possible to crash the kernel in several different ways by sending
messages to the SMC_PNETID generic netlink family that are missing the
expected attributes:

- Missing SMC_PNETID_NAME => null pointer dereference when comparing
  names.
- Missing SMC_PNETID_ETHNAME => null pointer dereference accessing
  smc_pnetentry::ndev.
- Missing SMC_PNETID_IBNAME => null pointer dereference accessing
  smc_pnetentry::smcibdev.
- Missing SMC_PNETID_IBPORT => out of bounds array access to
  smc_ib_device::pattr[-1].

Fix it by validating that all expected attributes are present and that
SMC_PNETID_IBPORT is nonzero.

Reported-by: syzbot+5cd61039dc9b8bfa6...@syzkaller.appspotmail.com
Fixes: 6812baabf24d ("smc: establish pnet table management")
Cc: <sta...@vger.kernel.org> # v4.11+
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/smc/smc_pnet.c | 71 ++
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c
index 74568cdbca708..d7b88b2d1b224 100644
--- a/net/smc/smc_pnet.c
+++ b/net/smc/smc_pnet.c
@@ -245,40 +245,45 @@ static struct smc_ib_device *smc_pnet_find_ib(char 
*ib_name)
 static int smc_pnet_fill_entry(struct net *net, struct smc_pnetentry *pnetelem,
   struct nlattr *tb[])
 {
-   char *string, *ibname = NULL;
-   int rc = 0;
+   char *string, *ibname;
+   int rc;
 
memset(pnetelem, 0, sizeof(*pnetelem));
INIT_LIST_HEAD(>list);
-   if (tb[SMC_PNETID_NAME]) {
-   string = (char *)nla_data(tb[SMC_PNETID_NAME]);
-   if (!smc_pnetid_valid(string, pnetelem->pnet_name)) {
-   rc = -EINVAL;
-   goto error;
-   }
-   }
-   if (tb[SMC_PNETID_ETHNAME]) {
-   string = (char *)nla_data(tb[SMC_PNETID_ETHNAME]);
-   pnetelem->ndev = dev_get_by_name(net, string);
-   if (!pnetelem->ndev)
-   return -ENOENT;
-   }
-   if (tb[SMC_PNETID_IBNAME]) {
-   ibname = (char *)nla_data(tb[SMC_PNETID_IBNAME]);
-   ibname = strim(ibname);
-   pnetelem->smcibdev = smc_pnet_find_ib(ibname);
-   if (!pnetelem->smcibdev) {
-   rc = -ENOENT;
-   goto error;
-   }
-   }
-   if (tb[SMC_PNETID_IBPORT]) {
-   pnetelem->ib_port = nla_get_u8(tb[SMC_PNETID_IBPORT]);
-   if (pnetelem->ib_port > SMC_MAX_PORTS) {
-   rc = -EINVAL;
-   goto error;
-   }
-   }
+
+   rc = -EINVAL;
+   if (!tb[SMC_PNETID_NAME])
+   goto error;
+   string = (char *)nla_data(tb[SMC_PNETID_NAME]);
+   if (!smc_pnetid_valid(string, pnetelem->pnet_name))
+   goto error;
+
+   rc = -EINVAL;
+   if (!tb[SMC_PNETID_ETHNAME])
+   goto error;
+   rc = -ENOENT;
+   string = (char *)nla_data(tb[SMC_PNETID_ETHNAME]);
+   pnetelem->ndev = dev_get_by_name(net, string);
+   if (!pnetelem->ndev)
+   goto error;
+
+   rc = -EINVAL;
+   if (!tb[SMC_PNETID_IBNAME])
+   goto error;
+   rc = -ENOENT;
+   ibname = (char *)nla_data(tb[SMC_PNETID_IBNAME]);
+   ibname = strim(ibname);
+   pnetelem->smcibdev = smc_pnet_find_ib(ibname);
+   if (!pnetelem->smcibdev)
+   goto error;
+
+   rc = -EINVAL;
+   if (!tb[SMC_PNETID_IBPORT])
+   goto error;
+   pnetelem->ib_port = nla_get_u8(tb[SMC_PNETID_IBPORT]);
+   if (pnetelem->ib_port < 1 || pnetelem->ib_port > SMC_MAX_PORTS)
+   goto error;
+
return 0;
 
 error:
@@ -307,6 +312,8 @@ static int smc_pnet_get(struct sk_buff *skb, struct 
genl_info *info)
void *hdr;
int rc;
 
+   if (!info->attrs[SMC_PNETID_NAME])
+   return -EINVAL;
pnetelem = smc_pnet_find_pnetid(
(char *)nla_data(info->attrs[SMC_PNETID_NAME]));
if (!pnetelem)
@@ -359,6 +366,8 @@ static int smc_pnet_add(struct sk_buff *skb, struct 
genl_info *info)
 
 static int smc_pnet_del(struct sk_buff *skb, struct genl_info *info)
 {
+   if (!info->attrs[SMC_PNETID_NAME])
+   return -EINVAL;
return smc_pnet_remove_by_pnetid(
(char *)nla_data(info->attrs[SMC_PNETID_NAME]));
 }
-- 
2.17.0

Re: general protection fault in rds_ib_get_mr

[Eric Biggers]

On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 3215b9d57a2c75c4305a3956ca303d7004485200 (Wed Mar 21 00:44:27 2018 +)
> Merge tag 'clk-fixes-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=b51c77ef956678a65834
> 
> So far this crash happened 4 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b51c77ef956678a65...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1521615317.627:7): avc:  denied  { map } for
> pid=4240 comm="syzkaller468044" path="/root/syzkaller468044973" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4244 Comm: syzkaller468044 Not tainted 4.16.0-rc6+ #361
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544
> RSP: 0018:8801b059f890 EFLAGS: 00010202
> RAX: dc00 RBX: 8801b07e1300 RCX: 8562d96e
> RDX: 000d RSI: 0001 RDI: 0068
> RBP: 8801b059f8b8 R08: ed0036274244 R09: 8801b13a1200
> R10: 0004 R11: ed0036274243 R12: 8801b13a1200
> R13: 0001 R14: 8801ca09fa9c R15: 
> FS:  7f4d050af700() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f4d050aee78 CR3: 0001b0d9b006 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  __rds_rdma_map+0x710/0x1050 net/rds/rdma.c:271
>  rds_get_mr_for_dest+0x1d4/0x2c0 net/rds/rdma.c:357
>  rds_setsockopt+0x6cc/0x980 net/rds/af_rds.c:347
>  SYSC_setsockopt net/socket.c:1849 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1828
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x4456d9
> RSP: 002b:7f4d050aedb8 EFLAGS: 0246 ORIG_RAX: 0036
> RAX: ffda RBX: 006dac3c RCX: 004456d9
> RDX: 0007 RSI: 0114 RDI: 0004
> RBP: 006dac38 R08: 00a0 R09: 
> R10: 2380 R11: 0246 R12: 
> R13: 7fffbfb36d6f R14: 7f4d050af9c0 R15: 0005
> Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 cc 01 00 00 4c 8b bb 80 04 00 00 48
> b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 9c 01 00 00 4d 8b 7f 68 48 b8 00 00 00 00 00
> RIP: rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544 RSP: 8801b059f890
> ---[ end trace 7e1cea13b85473b0 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
(next-20180511).  Here's a simplified reproducer:

#include 
#include 
#include 

int main()
{
int transport = RDS_TRANS_IB;
int fd;

fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
setsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, , 
sizeof(transport));

if (fork()) {
for (;;) {
struct sockaddr_in addr = {
 

Re: INFO: trying to register non-static key in del_timer_sync

[Eric Biggers]

On Sun, Jan 28, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +)
> Merge tag 'riscv-for-linus-4.15-maintainers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux
> 
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3659f05802671eb8a...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1517074079.617:7): avc:  denied  { map } for
> pid=3685 comm="syzkaller985951" path="/root/syzkaller985951088" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  register_lock_class+0x542/0x2cd0 kernel/locking/lockdep.c:752
>  __lock_acquire+0x1de/0x3e00 kernel/locking/lockdep.c:3314
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
>  del_timer_sync+0xba/0x240 kernel/time/timer.c:1275
>  led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
>  cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
>  do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
>  nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
>  nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
>  ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
>  SYSC_setsockopt net/socket.c:1831 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1810
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4449fa
> RSP: 002b:7ffee653a948 EFLAGS: 0206 ORIG_RAX: 0036
> RAX: ffda RBX: 006cd0fc RCX: 004449fa
> RDX: 0040 RSI:  RDI: 0003
> RBP: 006cd0fc R08: 02d8 R09: 0117c880
> R10: 006cd528 R11: 0206 R12: 0003
> R13: 006d00a4 R14: 006d0050 R15: 004a39ae
> [ cut here ]
> ODEBUG: assert_init not available (active state 0) object type: timer_list
> hint:   (null)
> WARNING: CPU: 1 PID: 3685 at lib/debugobjects.c:291
> debug_print_object+0x166/0x220 lib/debugobjects.c:288
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3685 Comm: syzkaller985951 Not tainted 4.15.0-rc9+ #283
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1096
> RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
> RSP: 0018:8801d9adf7d0 EFLAGS: 00010282
> RAX: dc08 RBX: 0005 RCX: 8159ebae
> RDX:  RSI: 0001 RDI: 0293
> RBP: 8801d9adf810 R08:  R09: 11003b35be97
> R10: 8801d9adf6d0 R11: 86b38678 R12: 0001
> R13: 86b49d00 R14: 86010440 R15: 815f1530
>  debug_object_assert_init+0x303/0x570 lib/debugobjects.c:654
>  debug_timer_assert_init kernel/time/timer.c:707 [inline]
>  debug_assert_init kernel/time/timer.c:759 [inline]
>  try_to_del_timer_sync+0x74/0x130 kernel/time/timer.c:1215
>  del_timer_sync+0x18a/0x240 kernel/time/timer.c:1285
>  led_tg_destroy+0x2dd/0x3f0 net/netfilter/xt_LED.c:185
>  cleanup_entry+0x218/0x350 net/ipv4/netfilter/ip_tables.c:659
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1096
>  do_replace net/ipv4/netfilter/ip_tables.c:1152 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1682
>  nf_sockopt net/netfilter/nf_sockopt.c:106 

Re: BUG: unable to handle kernel paging request in cgroup_mt_destroy_v1

[Eric Biggers]

On Wed, Jan 31, 2018 at 05:58:01PM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 3da90b159b146672f830bcd2489dd3a1f4e9e089 (Wed Jan 31 03:07:32 2018 +)
> Merge tag 'f2fs-for-4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
> 
> So far this crash happened 3 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+eeed2602160e4cc17...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1517426494.787:7): avc:  denied  { map } for
> pid=4176 comm="syzkaller493328" path="/root/syzkaller493328633" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> BUG: unable to handle kernel paging request at ff6d
> IP: css_put include/linux/cgroup.h:386 [inline]
> IP: cgroup_put include/linux/cgroup.h:415 [inline]
> IP: cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102
> PGD 6a25067 P4D 6a25067 PUD 6a27067 PMD 0
> Oops:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4176 Comm: syzkaller493328 Not tainted 4.15.0+ #288
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:css_put include/linux/cgroup.h:386 [inline]
> RIP: 0010:cgroup_put include/linux/cgroup.h:415 [inline]
> RIP: 0010:cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102
> RSP: 0018:8801b19e7958 EFLAGS: 00010246
> RAX: 0008 RBX: 11003633cf2b RCX: 847188c6
> RDX:  RSI: 8709b900 RDI: ff6d
> RBP: 8801b19e79e0 R08: 11003633cef9 R09: 
> R10:  R11:  R12: ff01
> R13: 8801b19e79b8 R14: dc00 R15: 84718810
> FS:  00c16880() GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: ff6d CR3: 0001b1f38004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  cleanup_match+0x14e/0x220 net/ipv6/netfilter/ip6_tables.c:481
>  cleanup_entry+0xcb/0x350 net/ipv4/netfilter/ip_tables.c:646
>  __do_replace+0x7d7/0xa90 net/ipv4/netfilter/ip_tables.c:1091
>  do_replace net/ipv4/netfilter/ip_tables.c:1147 [inline]
>  do_ipt_set_ctl+0x40f/0x5f0 net/ipv4/netfilter/ip_tables.c:1677
>  nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
>  nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
>  ip_setsockopt+0xa1/0xb0 net/ipv4/ip_sockglue.c:1256
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2875
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2968
>  SYSC_setsockopt net/socket.c:1831 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1810
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x4408a9
> RSP: 002b:7ffddd061cc8 EFLAGS: 0207 ORIG_RAX: 0036
> RAX: ffda RBX:  RCX: 004408a9
> RDX: 0040 RSI:  RDI: 0004
> RBP: faaff2414ccfc19e R08: 12f0 R09: 
> R10: 2000b000 R11: 0207 R12: 886f734548d4d66b
> R13: ff01 R14:  R15: 
> Code: 6c 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48
> 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 a6 01 00 00 <41> f6 44 24 6c
> 01 74 2e e8 be 06 ff fc 48 b8 00 00 00 00 00 fc
> RIP: css_put include/linux/cgroup.h:386 [inline] RSP: 8801b19e7958
> RIP: cgroup_put include/linux/cgroup.h:415 [inline] RSP: 8801b19e7958
> RIP: cgroup_mt_destroy_v1+0xe5/0x310 net/netfilter/xt_cgroup.c:102 RSP:
> 8801b19e7958
> CR2: ff6d
> ---[ end trace bfd8c145aa41ae03 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title

This was fixed by commit ba7cd5d95f25cc6:

#syz fix: netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()

- Eric

Re: KASAN: use-after-free Read in sit_tunnel_xmit

[Eric Biggers]

On Thu, Feb 15, 2018 at 04:22:28PM -0800, Cong Wang wrote:
> On Tue, Feb 13, 2018 at 10:48 AM, Dmitry Vyukov  wrote:
> > On Mon, Oct 30, 2017 at 7:41 PM, Cong Wang  wrote:
> >> On Mon, Oct 30, 2017 at 8:34 AM, syzbot
> >> 
> >> wrote:
> >>> Hello,
> >>>
> >>> syzkaller hit the following crash on
> >>> 4dc12ffeaeac939097a3f55c881d3dc3523dff0c
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> >>> compiler: gcc (GCC) 7.1.1 20170620
> >>> .config is attached
> >>> Raw console output is attached.
> >>>
> >>> skbuff: bad partial csum: csum=53081/14726 len=2273
> >>> ==
> >>> BUG: KASAN: use-after-free in ipv6_get_dsfield include/net/dsfield.h:23
> >>> [inline]
> >>> BUG: KASAN: use-after-free in ipip6_tunnel_xmit net/ipv6/sit.c:968 
> >>> [inline]
> >>> BUG: KASAN: use-after-free in sit_tunnel_xmit+0x2a41/0x3130
> >>> net/ipv6/sit.c:1016
> >>> Read of size 2 at addr 8801c64afd00 by task syz-executor3/16942
> >>>
> >>> CPU: 0 PID: 16942 Comm: syz-executor3 Not tainted 4.14.0-rc5+ #97
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >>> Google 01/01/2011
> >>> Call Trace:
> >>>  __dump_stack lib/dump_stack.c:16 [inline]
> >>>  dump_stack+0x194/0x257 lib/dump_stack.c:52
> >>>  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >>>  kasan_report_error mm/kasan/report.c:351 [inline]
> >>>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >>>  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
> >>>  ipv6_get_dsfield include/net/dsfield.h:23 [inline]
> >>>  ipip6_tunnel_xmit net/ipv6/sit.c:968 [inline]
> >>>  sit_tunnel_xmit+0x2a41/0x3130 net/ipv6/sit.c:1016
> >>>  __netdev_start_xmit include/linux/netdevice.h:4022 [inline]
> >>>  netdev_start_xmit include/linux/netdevice.h:4031 [inline]
> >>>  xmit_one net/core/dev.c:3008 [inline]
> >>>  dev_hard_start_xmit+0x248/0xac0 net/core/dev.c:3024
> >>>  __dev_queue_xmit+0x17d2/0x2070 net/core/dev.c:3505
> >>>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3538
> >>>  neigh_direct_output+0x15/0x20 net/core/neighbour.c:1390
> >>>  neigh_output include/net/neighbour.h:481 [inline]
> >>>  ip6_finish_output2+0xad1/0x22a0 net/ipv6/ip6_output.c:120
> >>>  ip6_fragment+0x25ae/0x3420 net/ipv6/ip6_output.c:723
> >>>  ip6_finish_output+0x319/0x920 net/ipv6/ip6_output.c:144
> >>>  NF_HOOK_COND include/linux/netfilter.h:238 [inline]
> >>>  ip6_output+0x1f4/0x850 net/ipv6/ip6_output.c:163
> >>>  dst_output include/net/dst.h:459 [inline]
> >>>  ip6_local_out+0x95/0x160 net/ipv6/output_core.c:176
> >>>  ip6_send_skb+0xa1/0x330 net/ipv6/ip6_output.c:1658
> >>>  ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1678
> >>>  rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
> >>>  rawv6_sendmsg+0x2eb9/0x3e40 net/ipv6/raw.c:935
> >>>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
> >>>  sock_sendmsg_nosec net/socket.c:633 [inline]
> >>>  sock_sendmsg+0xca/0x110 net/socket.c:643
> >>>  SYSC_sendto+0x352/0x5a0 net/socket.c:1750
> >>>  SyS_sendto+0x40/0x50 net/socket.c:1718
> >>>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> >>> RIP: 0033:0x452869
> >>> RSP: 002b:7fe3c12e5be8 EFLAGS: 0212 ORIG_RAX: 002c
> >>> RAX: ffda RBX: 007580d8 RCX: 00452869
> >>> RDX: 07f1 RSI: 2013b7ff RDI: 0014
> >>> RBP: 0161 R08: 204e8fe4 R09: 001c
> >>> R10: 0100 R11: 0212 R12: 006f01b8
> >>> R13:  R14: 7fe3c12e66d4 R15: 0017
> >>>
> >>> Allocated by task 16924:
> >>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> >>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>>  set_track mm/kasan/kasan.c:459 [inline]
> >>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> >>>  __do_kmalloc_node mm/slab.c:3689 [inline]
> >>>  __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3703
> >>>  __kmalloc_reserve.isra.40+0x41/0xd0 net/core/skbuff.c:138
> >>>  __alloc_skb+0x13b/0x780 net/core/skbuff.c:206
> >>>  alloc_skb include/linux/skbuff.h:985 [inline]
> >>>  sock_wmalloc+0x140/0x1d0 net/core/sock.c:1932
> >>>  __ip6_append_data.isra.43+0x2681/0x3340 net/ipv6/ip6_output.c:1397
> >>>  ip6_append_data+0x189/0x290 net/ipv6/ip6_output.c:1552
> >>>  rawv6_sendmsg+0x1dd9/0x3e40 net/ipv6/raw.c:928
> >>>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
> >>>  sock_sendmsg_nosec net/socket.c:633 [inline]
> >>>  sock_sendmsg+0xca/0x110 net/socket.c:643
> >>>  SYSC_sendto+0x352/0x5a0 net/socket.c:1750
> >>>  SyS_sendto+0x40/0x50 net/socket.c:1718
> >>>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> >>>
> >>> Freed by task 16942:
> >>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> >>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>>  set_track mm/kasan/kasan.c:459 [inline]
> >>>  

Re: KASAN: use-after-free Read in sctp_packet_transmit

[Eric Biggers]

On Fri, Jan 05, 2018 at 02:07:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 8a4816cad00bf14642f0ed6043b32d29a05006ce
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5adcca18fca253b4c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> ==
> BUG: KASAN: use-after-free in sctp_packet_transmit+0x3505/0x3750
> net/sctp/output.c:643
> Read of size 8 at addr 8801bda9fb80 by task modprobe/23740
> 
> CPU: 1 PID: 23740 Comm: modprobe Not tainted 4.15.0-rc5+ #175
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  sctp_packet_transmit+0x3505/0x3750 net/sctp/output.c:643
>  sctp_outq_flush+0x121b/0x4060 net/sctp/outqueue.c:1197
>  sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:776
>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1807 [inline]
>  sctp_side_effects net/sctp/sm_sideeffect.c:1210 [inline]
>  sctp_do_sm+0x4e0/0x6ed0 net/sctp/sm_sideeffect.c:1181
>  sctp_generate_heartbeat_event+0x292/0x3f0 net/sctp/sm_sideeffect.c:406
>  call_timer_fn+0x228/0x820 kernel/time/timer.c:1320
>  expire_timers kernel/time/timer.c:1357 [inline]
>  __run_timers+0x7ee/0xb70 kernel/time/timer.c:1660
>  run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  invoke_softirq kernel/softirq.c:365 [inline]
>  irq_exit+0x1cc/0x200 kernel/softirq.c:405
>  exiting_irq arch/x86/include/asm/apic.h:540 [inline]
>  smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:904
>  
> RIP: 0010:__preempt_count_add arch/x86/include/asm/preempt.h:76 [inline]
> RIP: 0010:__rcu_read_lock include/linux/rcupdate.h:83 [inline]
> RIP: 0010:rcu_read_lock include/linux/rcupdate.h:629 [inline]
> RIP: 0010:__is_insn_slot_addr+0x8f/0x330 kernel/kprobes.c:303
> RSP: 0018:8801d4937430 EFLAGS: 0283 ORIG_RAX: ff11
> RAX: 8801bf13c000 RBX: 8656dd00 RCX: 8170bd88
> RDX:  RSI:  RDI: 8656dd00
> RBP: 8801d4937518 R08:  R09: 11003a926e67
> R10: 8801d4937300 R11:  R12: 
> R13:  R14: 8801d49374f0 R15: 8801dae230c0
>  is_kprobe_insn_slot include/linux/kprobes.h:318 [inline]
>  kernel_text_address+0x132/0x140 kernel/extable.c:150
>  __kernel_text_address+0xd/0x40 kernel/extable.c:107
>  unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:18
>  __save_stack_trace+0x7e/0xd0 arch/x86/kernel/stacktrace.c:45
>  save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>  kmem_cache_zalloc include/linux/slab.h:678 [inline]
>  file_alloc_security security/selinux/hooks.c:369 [inline]
>  selinux_file_alloc_security+0xae/0x190 security/selinux/hooks.c:3454
>  security_file_alloc+0x6d/0xa0 security/security.c:873
>  get_empty_filp+0x189/0x4f0 fs/file_table.c:129
>  path_openat+0xed/0x3530 fs/namei.c:3496
>  do_filp_open+0x25b/0x3b0 fs/namei.c:3554
>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>  SYSC_open fs/open.c:1077 [inline]
>  SyS_open+0x2d/0x40 fs/open.c:1072
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x7efdff1bb120
> RSP: 002b:7ffde6213c08 EFLAGS: 0246 ORIG_RAX: 0002
> RAX: ffda RBX: 55c34fab4090 RCX: 7efdff1bb120
> RDX: 01b6 RSI: 0008 RDI: 7ffde6213d20
> RBP: 7ffde6214d90 R08: 0008 R09: 0001
> R10:  R11: 0246 R12: 55c34fab4090
> R13: 7ffde6215de0 R14:  R15: 
> 
> Allocated by task 23739:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>  kmem_cache_zalloc include/linux/slab.h:678 [inline]
>  sctp_chunkify+0xce/0x3f0 

Re: KASAN: use-after-free Read in __dev_queue_xmit

[Eric Biggers]

On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
> On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote:
> > Note: all commands must start from beginning of the line in the email body.
> > 
> > I guess skb_probe_transport_header() should be hardened to reject malicious
> > packets given by user space, instead of being gentle.
> 
> Although bug triggered for this particular repro is in flow dissector
> :/
> 
> I will test :
> 
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 
> 15ce300637650e17fcab7e378b20fe7972686d46..544bddf08e13c7f6e47aadc737244c9ba5af56b2
>  100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -976,8 +976,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>  out_good:
> ret = true;
>  
> -   key_control->thoff = (u16)nhoff;
>  out:
> +   key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> key_basic->n_proto = proto;
> key_basic->ip_proto = ip_proto;
>  
> @@ -985,7 +985,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>  
>  out_bad:
> ret = false;
> -   key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> goto out;
>  }
>  EXPORT_SYMBOL(__skb_flow_dissect);

Fix for this was commit d0c081b49137cd:

#syz fix: flow_dissector: properly cap thoff field

But a crash with the same signature is still occurring, so it should eventually
get reported again.  C reproducer is here, it works on Linus' tree (commit
036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC=105b1ae780

- Eric

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers <ebigge...@gmail.com> wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of 
> >> git://git.k..
> >> git tree:   upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> >>
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> random: sshd: uninitialized urandom read (32 bytes read)
> >> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> >> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> >> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> >> net/dccp/ccids/lib/packet_history.c:422
> >>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
> >>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> >>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> >>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> >>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
> >>  sk_backlog_rcv include/net/sock.h:909 [inline]
> >>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
> >>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
> >>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
> >>  dst_input include/net/dst.h:450 [inline]
> >>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
> >>  NF_HOOK include/linux/netfilter.h:288 [inline]
> >>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
> >>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
> >>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
> >>  process_backlog+0x219/0x760 net/core/dev.c:5337
> >>  napi_poll net/core/dev.c:5735 [inline]
> >>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
> >>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> >>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
> >>  
> >>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
> >>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
> >>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
> >>  local_bh_enable include/linux/bottom_half.h:32 [inline]
> >>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
> >>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
> >>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
> >>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
> >>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
> >>  dst_output include/net/dst.h:444 [inline]
> >>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> >>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
> >>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
> >>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
> >>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
> >>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
> >>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 net/socket.c:639
> >>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
> >>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
> >>  __do_sys_sendmmsg net/socket.c:2241 [i

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[Eric Biggers]

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
> dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com
> 
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
>  ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>  dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
>  dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
>  dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
>  sk_backlog_rcv include/net/sock.h:909 [inline]
>  __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
>  dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
>  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
>  dst_input include/net/dst.h:450 [inline]
>  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
>  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
>  process_backlog+0x219/0x760 net/core/dev.c:5337
>  napi_poll net/core/dev.c:5735 [inline]
>  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
>  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
>  
>  do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
>  do_softirq arch/x86/include/asm/preempt.h:23 [inline]
>  __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
>  ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
>  ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>  ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
>  dst_output include/net/dst.h:444 [inline]
>  ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
>  ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
>  dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
>  dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
>  dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
>  dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
>  inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
>  sock_sendmsg_nosec net/socket.c:629 [inline]
>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>  ___sys_sendmsg+0x525/0x940 net/socket.c:2117
>  __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
>  __do_sys_sendmmsg net/socket.c:2241 [inline]
>  __se_sys_sendmmsg net/socket.c:2238 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x445d09
> RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
> RAX: ffda RBX: 006dac40 RCX: 00445d09
> RDX: 0001 RSI: 00
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report

There's already a bug report 

Re: KASAN: out-of-bounds Read in ip6_xmit

[Eric Biggers]

On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on net-next commit
> 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +)
> Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c8e66da874feb11aa...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> ==
> BUG: KASAN: out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:192 [inline]
> BUG: KASAN: out-of-bounds in ip6_xmit+0x1f76/0x2260
> net/ipv6/ip6_output.c:264
> Read of size 8 at addr 8801bcc8cc18 by task syz-executor2/11459
> 
> CPU: 0 PID: 11459 Comm: syz-executor2 Not tainted 4.15.0-rc9+ #212
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:192 [inline]
>  ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  l2tp_xmit_core net/l2tp/l2tp_core.c:1096 [inline]
>  l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1191
>  pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2080
>  SYSC_sendmsg net/socket.c:2091 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2087
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x453299
> RSP: 002b:7fcfef194c58 EFLAGS: 0212 ORIG_RAX: 002e
> RAX: ffda RBX: 0071bf58 RCX: 00453299
> RDX: 0081 RSI: 2037ffc8 RDI: 0014
> RBP: 036f R08:  R09: 
> R10:  R11: 0212 R12: 006f4308
> R13:  R14: 7fcfef1956d4 R15: 000b
> 
> Allocated by task 11466:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1497
>  ip_route_input_slow net/ipv4/route.c:2006 [inline]
>  ip_route_input_rcu+0x1076/0x3200 net/ipv4/route.c:2137
>  ip_route_input_noref+0xf5/0x1e0 net/ipv4/route.c:2083
>  ip_rcv_finish+0x3a6/0x2040 net/ipv4/ip_input.c:348
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
>  __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4547
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4612
>  netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4686
>  netif_receive_skb+0xae/0x390 net/core/dev.c:4710
>  tun_rx_batched.isra.53+0x5ee/0x870 drivers/net/tun.c:1558
>  tun_get_user+0x25de/0x3940 drivers/net/tun.c:1958
>  tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1986
>  call_write_iter include/linux/fs.h:1772 [inline]
>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
>  do_iter_write+0x154/0x540 fs/read_write.c:932
>  vfs_writev+0x18a/0x340 fs/read_write.c:977
>  do_writev+0xfc/0x2a0 fs/read_write.c:1012
>  SYSC_writev fs/read_write.c:1085 [inline]
>  SyS_writev+0x27/0x30 fs/read_write.c:1082
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> 
> Freed by task 7176:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
>  dst_destroy+0x257/0x370 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:195 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2996
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801bcc8cc00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is located 24 bytes inside of
>  168-byte region [8801bcc8cc00, 8801bcc8cca8)
> The buggy address belongs to the page:
> 

Re: KASAN: use-after-free Read in ip6_xmit

[Eric Biggers]

On Thu, Jan 04, 2018 at 02:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56029fd3642567f39...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514737122.010:7): avc:  denied  { map } for
> pid=3153 comm="syzkaller920384" path="/root/syzkaller920384627" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:189
> [inline]
> BUG: KASAN: use-after-free in ip6_xmit+0x1f92/0x1fc0
> net/ipv6/ip6_output.c:248
> Read of size 8 at addr 8801ca6f9f18 by task syzkaller920384/3153
> 
> CPU: 1 PID: 3153 Comm: syzkaller920384 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  ip6_dst_idev include/net/ip6_fib.h:189 [inline]
>  ip6_xmit+0x1f92/0x1fc0 net/ipv6/ip6_output.c:248
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_send_syn_data net/ipv4/tcp_output.c:3456 [inline]
>  tcp_connect+0x1ed5/0x4090 net/ipv4/tcp_output.c:3495
>  tcp_v4_connect+0x15ef/0x1e70 net/ipv4/tcp_ipv4.c:257
>  __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
>  tcp_sendmsg_fastopen net/ipv4/tcp.c:1167 [inline]
>  tcp_sendmsg_locked+0x27e4/0x3b30 net/ipv4/tcp.c:1212
>  tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1459
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  SYSC_sendto+0x361/0x5c0 net/socket.c:1719
>  SyS_sendto+0x40/0x50 net/socket.c:1687
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fda9
> RSP: 002b:7ffc9b8bd818 EFLAGS: 0217 ORIG_RAX: 002c
> RAX: ffda RBX:  RCX: 0043fda9
> RDX:  RSI: 20aa1000 RDI: 0003
> RBP: 006ca018 R08: 20aa1000 R09: 0010
> R10: 23ff R11: 0217 R12: 00401710
> R13: 004017a0 R14:  R15: 
> 
> Allocated by task 3140:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3545
>  dst_alloc+0x11f/0x1a0 net/core/dst.c:104
>  rt_dst_alloc+0xe9/0x520 net/ipv4/route.c:1500
>  __mkroute_output net/ipv4/route.c:2242 [inline]
>  ip_route_output_key_hash_rcu+0xa40/0x2c10 net/ipv4/route.c:2470
>  ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2299
>  __ip_route_output_key include/net/route.h:125 [inline]
>  ip_route_connect include/net/route.h:300 [inline]
>  __ip4_datagram_connect+0xa67/0x1240 net/ipv4/datagram.c:51
>  __ip6_datagram_connect+0x709/0xf90 net/ipv6/datagram.c:157
>  ip6_datagram_connect+0x2f/0x50 net/ipv6/datagram.c:274
>  inet_dgram_connect+0x16b/0x1f0 net/ipv4/af_inet.c:542
>  SYSC_connect+0x213/0x4a0 net/socket.c:1611
>  SyS_connect+0x24/0x30 net/socket.c:1592
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 0:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3489 [inline]
>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3747
>  dst_destroy+0x219/0x310 net/core/dst.c:140
>  dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801ca6f9f00
>  which belongs to the cache ip_dst_cache of size 168
> The buggy address is 

Re: KASAN: use-after-free Read in work_is_static_object

[Eric Biggers]

On Mon, Jan 08, 2018 at 12:58:11PM +0100, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Mon, Jan 8, 2018 at 12:55 PM, Dmitry Vyukov  wrote:
> > On Mon, Jan 8, 2018 at 12:43 PM, syzbot
> >  wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> f66faae2f80a45feafc04ce63ef744ac4b6e8c05
> >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> Unfortunately, I don't have any reproducer for this bug yet.
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+40396d275b34b0dd5...@syzkaller.appspotmail.com
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.
> >
> >
> > This looks like an issue in kcm sockets, so +kcm maintainers.
> 
> FTR, guilty file extraction was fixed to ignore kernel/workqueue.c:
> https://github.com/google/syzkaller/commit/1014e5506e35965f3bad13fabb08666134d0b273
> Presumably for bugs in workqueue usually the caller is guilty.
> 
> 
> >> device ip6_vti0 entered promiscuous mode
> >> ==
> >> BUG: KASAN: use-after-free in constant_test_bit
> >> arch/x86/include/asm/bitops.h:325 [inline]
> >> BUG: KASAN: use-after-free in work_is_static_object+0x39/0x40
> >> kernel/workqueue.c:443
> >> Read of size 8 at addr 8801beca5788 by task syz-executor2/12922
> >>
> >> CPU: 0 PID: 12922 Comm: syz-executor2 Not tainted 4.15.0-rc5+ #178
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  __dump_stack lib/dump_stack.c:17 [inline]
> >>  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >>  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >>  kasan_report_error mm/kasan/report.c:351 [inline]
> >>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> >>  constant_test_bit arch/x86/include/asm/bitops.h:325 [inline]
> >>  work_is_static_object+0x39/0x40 kernel/workqueue.c:443
> >>  debug_object_activate+0x36f/0x730 lib/debugobjects.c:470
> >>  debug_work_activate kernel/workqueue.c:492 [inline]
> >>  __queue_work+0x163/0x1230 kernel/workqueue.c:1381
> >>  queue_work_on+0x16a/0x1c0 kernel/workqueue.c:1487
> >>  queue_work include/linux/workqueue.h:488 [inline]
> >>  strp_check_rcv+0x25/0x30 net/strparser/strparser.c:552
> >>  kcm_attach net/kcm/kcmsock.c:1439 [inline]
> >>  kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
> >>  kcm_ioctl+0x82f/0x1690 net/kcm/kcmsock.c:1665
> >>  sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >>  sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >>  vfs_ioctl fs/ioctl.c:46 [inline]
> >>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >>  SYSC_ioctl fs/ioctl.c:701 [inline]
> >>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> >>  entry_SYSCALL_64_fastpath+0x23/0x9a
> >> RIP: 0033:0x452ac9
> >> RSP: 002b:7f1bbd860c58 EFLAGS: 0212 ORIG_RAX: 0010
> >> RAX: ffda RBX: 0071bea0 RCX: 00452ac9
> >> RDX: 20954ff8 RSI: 89e0 RDI: 0017
> >> RBP: 057b R08:  R09: 
> >> R10:  R11: 0212 R12: 006f6428
> >> R13:  R14: 7f1bbd8616d4 R15: 
> >>
> >> Allocated by task 12922:
> >>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>  set_track mm/kasan/kasan.c:459 [inline]
> >>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> >>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> >>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3544
> >>  kmem_cache_zalloc include/linux/slab.h:678 [inline]
> >>  kcm_attach net/kcm/kcmsock.c:1394 [inline]
> >>  kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
> >>  kcm_ioctl+0x2d2/0x1690 net/kcm/kcmsock.c:1665
> >>  sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >>  sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >>  vfs_ioctl fs/ioctl.c:46 [inline]
> >>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >>  SYSC_ioctl fs/ioctl.c:701 [inline]
> >>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> >>  entry_SYSCALL_64_fastpath+0x23/0x9a
> >>
> >> Freed by task 12929:
> >>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>  set_track mm/kasan/kasan.c:459 [inline]
> >>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> >>  __cache_free mm/slab.c:3488 [inline]
> >>  kmem_cache_free+0x83/0x2a0 mm/slab.c:3746
> >>  kcm_unattach+0xe53/0x1510 net/kcm/kcmsock.c:1563
> >>  kcm_unattach_ioctl net/kcm/kcmsock.c:1608 [inline]
> >>  kcm_ioctl+0xe54/0x1690 net/kcm/kcmsock.c:1675
> >>  sock_do_ioctl+0x65/0xb0 net/socket.c:956
> >>  sock_ioctl+0x2c2/0x440 net/socket.c:1053
> >>  vfs_ioctl fs/ioctl.c:46 [inline]
> >>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> >>  SYSC_ioctl 

Re: WARNING in perf_trace_buf_alloc (2)

[Eric Biggers]

[+bpf maintainers and netdev]

On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 5cb0512c02ecd7e6214e912e4c150f4219ac78e0
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 3008 at kernel/trace/trace_event_perf.c:274
> perf_trace_buf_alloc+0x12d/0x160 kernel/trace/trace_event_perf.c:273
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 0 PID: 3008 Comm: syzkaller609027 Not tainted 4.14.0-rc7+ #159
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x417 kernel/panic.c:181
>  __warn+0x1c4/0x1d9 kernel/panic.c:542
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
>  do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
>  do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
>  do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
>  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:906
> RIP: 0010:perf_trace_buf_alloc+0x12d/0x160
> kernel/trace/trace_event_perf.c:273
> RSP: 0018:8801c0fdf760 EFLAGS: 00010286
> RAX: 001c RBX: 1100381fbefe RCX: 
> RDX: 001c RSI: 1100381fbeac RDI: ed00381fbee0
> RBP: 8801c0fdf780 R08: 0001 R09: 
> R10: 8801c0fdf7a0 R11:  R12: 082c
> R13: 8801c0fdf810 R14: 8801c0fdf890 R15: 8801d8b34b40
>  perf_trace_bpf_map_keyval+0x260/0xbd0 include/trace/events/bpf.h:228
>  trace_bpf_map_update_elem include/trace/events/bpf.h:274 [inline]
>  map_update_elem kernel/bpf/syscall.c:597 [inline]
>  SYSC_bpf kernel/bpf/syscall.c:1478 [inline]
>  SyS_bpf+0x33eb/0x46a0 kernel/bpf/syscall.c:1453
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x445c29
> RSP: 002b:007eff68 EFLAGS: 0246 ORIG_RAX: 0141
> RAX: ffda RBX: 7ffe66adb340 RCX: 00445c29
> RDX: 0020 RSI: 2053dfe0 RDI: 0002
> RBP: 0082 R08:  R09: 
> R10:  R11: 0246 R12: 00403280
> R13: 00403310 R14:  R15: 
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line.

This still happens on Linus' tree.  It seems one of the BPF tracepoints is
trying to pass a buffer that is too long.  Here's a simplified reproducer that
works on Linus' tree (commit 5e7c7806111ade5).  Note: it's not 100% reliable for
some reason; you may have to run it a couple times.  Daniel or Alexei, can one
of you please look into this more?  Thanks!

#include 
#include 
#include 
#include 
#include 

int main()
{
int tracepoint_id;
FILE *f;

f = fopen("/sys/kernel/debug/tracing/events/bpf/bpf_map_update_elem/id",
  "r");
fscanf(f, "%d", _id);

struct perf_event_attr perf_attr = {
.type = PERF_TYPE_TRACEPOINT,
.size = sizeof(perf_attr),
.config = tracepoint_id,
};
syscall(__NR_perf_event_open, _attr, 0, 0, -1, 0);

for (;;) {
union bpf_attr create_attr = {
.map_type = BPF_MAP_TYPE_HASH,
.key_size = 4,
.value_size = 2048,
.max_entries = 1,
};
int fd = syscall(__NR_bpf, BPF_MAP_CREATE,
 _attr, sizeof(create_attr));

char key[4] = { 0 };
char value[2048] = { 0 };
union bpf_attr update_attr = {
.map_fd = fd,
.key = (unsigned long)key,
.value = 

Re: BUG: unable to handle kernel paging request in compat_copy_entries

[Eric Biggers]

On Mon, Mar 05, 2018 at 04:18:00PM +0100, Paolo Abeni wrote:
> On Mon, 2018-03-05 at 00:21 -0800, syzbot wrote:
> > Hello,
> > 
> > syzbot hit the following crash on upstream commit
> > 5fbdefcf685defd8bc5a8f37b17538d25c58d77a (Fri Mar 2 21:05:20 2018 +)
> > Merge branch 'parisc-4.16-1' of  
> > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
> > 
> > So far this crash happened 5 times on upstream.
> > syzkaller reproducer is attached.
> > Raw console output is attached.
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached.
> > user-space arch: i386
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5705ba91388d7bc30...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for  
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > audit: type=1400 audit(1520098078.492:8): avc:  denied  { map } for   
> > pid=4239 comm="syz-execprog" path="/root/syzkaller-shm255959590" dev="sda1" 
> >  
> > ino=16482 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023  
> > tcontext=unconfined_u:object_r:file_t:s0 tclass=file permissive=1
> > IPVS: ftp: loaded support on port[0] = 21
> > BUG: unable to handle kernel paging request at c90001819e4f
> > IP: ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline]
> > IP: size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline]
> > IP: compat_copy_entries+0x49f/0x1050 net/bridge/netfilter/ebtables.c:2160
> > PGD 1dad2f067 P4D 1dad2f067 PUD 1dad30067 PMD 1b2408067 PTE 0
> > Oops:  [#1] SMP KASAN
> > Dumping ftrace buffer:
> > (ftrace buffer empty)
> > Modules linked in:
> > CPU: 1 PID: 4249 Comm: syz-executor0 Not tainted 4.16.0-rc3+ #248
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
> > Google 01/01/2011
> > RIP: 0010:ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline]
> > RIP: 0010:size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline]
> > RIP: 0010:compat_copy_entries+0x49f/0x1050  
> > net/bridge/netfilter/ebtables.c:2160
> > RSP: 0018:8801b34bf7e8 EFLAGS: 00010246
> > RAX: 000a RBX: 8801b34bf9d4 RCX: c90001819e4f
> > RDX:  RSI:  RDI: 8801b34bf9d8
> > RBP: 8801b34bf968 R08:  R09: 
> > R10: 88613340 R11: 0001 R12: ee5f
> > R13: dc00 R14: 8801b34bf9c8 R15: c90001819e2f
> > FS:  () GS:8801db30(0063) knlGS:085b9900
> > CS:  0010 DS: 002b ES: 002b CR0: 80050033
> > CR2: c90001819e4f CR3: 0001b2bd7003 CR4: 001606e0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >   compat_do_replace+0x398/0x7c0 net/bridge/netfilter/ebtables.c:2249
> >   compat_do_ebt_set_ctl+0x22a/0x2d0 net/bridge/netfilter/ebtables.c:2330
> >   compat_nf_sockopt net/netfilter/nf_sockopt.c:144 [inline]
> >   compat_nf_setsockopt+0x88/0x130 net/netfilter/nf_sockopt.c:156
> >   compat_ip_setsockopt+0x8b/0xd0 net/ipv4/ip_sockglue.c:1285
> >   inet_csk_compat_setsockopt+0x95/0x120 net/ipv4/inet_connection_sock.c:1041
> >   compat_tcp_setsockopt+0x3d/0x70 net/ipv4/tcp.c:2916
> >   compat_sock_common_setsockopt+0xb2/0x140 net/core/sock.c:2986
> >   C_SYSC_setsockopt net/compat.c:403 [inline]
> >   compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386
> >   do_syscall_32_irqs_on arch/x86/entry/common.c:330 [inline]
> >   do_fast_syscall_32+0x3ec/0xf9f arch/x86/entry/common.c:392
> >   entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> > RIP: 0023:0xf7fbbc99
> > RSP: 002b:ffd5ab8c EFLAGS: 0286 ORIG_RAX: 016e
> > RAX: ffda RBX: 0003 RCX: 
> > RDX: 0080 RSI: 2280 RDI: 0208
> > RBP:  R08:  R09: 
> > R10:  R11:  R12: 
> > R13:  R14:  R15: 
> > Code: 8d 4f 20 48 89 c8 48 89 8d c8 fe ff ff 48 c1 e8 03 42 0f b6 14 28 48  
> > 89 c8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b2 0a 00 00 <45> 8b 67 20  
> > 44 39 a5 04 ff ff ff 0f 82 bd 08 00 00 e8 cb 52 56
> > RIP: ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline] RSP:  
> > 8801b34bf7e8
> > RIP: size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline] RSP:  
> > 8801b34bf7e8
> > RIP: compat_copy_entries+0x49f/0x1050 net/bridge/netfilter/ebtables.c:2160  
> > RSP: 8801b34bf7e8
> > CR2: c90001819e4f
> > ---[ end trace cf111332eb971f16 ]---
> > 
> > 
> > ---
> > This bug is generated by a dumb bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for details.
> > Direct all questions to syzkal...@googlegroups.com.
> > 
> > syzbot will keep track of 

Re: WARNING in refcount_inc (3)

[Eric Biggers]

On Sat, Mar 31, 2018 at 04:01:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 1379ef828a18d8f81c526b25e4d5685caa2cfd65 (Thu Mar 29 22:09:44 2018 +)
> Merge branch 'bpf-sockmap-ingress'
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=6eaf536fd743f5e119c5
> 
> So far this crash happened 6 times on bpf-next.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614614900998144
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5035340528091136
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5063394046509056
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-1280663959502969741
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6eaf536fd743f5e11...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> R13: 0005 R14: 1380 R15: 7ffd314c8768
> [ cut here ]
> [ cut here ]
> refcount_t: increment on 0; use-after-free.
> refcount_t: underflow; use-after-free.
> WARNING: CPU: 1 PID: 4434 at lib/refcount.c:153 refcount_inc+0x47/0x50
> lib/refcount.c:153
> WARNING: CPU: 0 PID: 4437 at lib/refcount.c:187
> refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:187
> Kernel panic - not syncing: panic_on_warn set ...
> 
> Modules linked in:
> CPU: 1 PID: 4434 Comm: syzkaller349430 Not tainted 4.16.0-rc6+ #41
> CPU: 0 PID: 4437 Comm: syzkaller349430 Not tainted 4.16.0-rc6+ #41
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:187
> Call Trace:
> RSP: 0018:8801b061f728 EFLAGS: 00010286
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x24d lib/dump_stack.c:53
> RAX: dc08 RBX:  RCX: 815ba4be
> RDX:  RSI: 1100360c3e95 RDI: 1100360c3e6a
> RBP: 8801b061f7b8 R08:  R09: 
> R10: 8801b061f850 R11:  R12: 1100360c3ee6
>  panic+0x1e4/0x41c kernel/panic.c:183
> R13:  R14: 0001 R15: 8801b1be4184
> FS:  01817880() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7ffd314c9000 CR3: 0001b04a1006 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x1f4/0x2b0 lib/bug.c:186
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
>  put_net include/net/net_namespace.h:222 [inline]
>  __sk_destruct+0x560/0x920 net/core/sock.c:1592
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
> RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
> RSP: 0018:8801b058f860 EFLAGS: 00010286
> RAX: dc08 RBX: 8801ab55a1c4 RCX: 815ba4be
> RDX:  RSI: 1100360b1ebc RDI: 1100360b1e91
> RBP: 8801b058f868 R08:  R09: 
>  sk_destruct+0x47/0x80 net/core/sock.c:1601
> R10:  R11:  R12: 8801b058faf8
>  __sk_free+0xf1/0x2b0 net/core/sock.c:1612
> R13: 8801af87b513 R14: 8801ab55a1c0 R15: 8801af87b501
>  sk_free+0x2a/0x40 net/core/sock.c:1623
>  sock_put include/net/sock.h:1661 [inline]
>  tcp_close+0x967/0x1190 net/ipv4/tcp.c:2329
>  get_net include/net/net_namespace.h:204 [inline]
>  sk_alloc+0x3f9/0x1440 net/core/sock.c:1540
>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:427
>  sock_release+0x8d/0x1e0 net/socket.c:594
>  sock_close+0x16/0x20 net/socket.c:1149
>  __fput+0x327/0x7e0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:243
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  inet_create+0x47c/0xf50 net/ipv4/af_inet.c:320
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x275/0x2f0 arch/x86/entry/common.c:166
>  __sock_create+0x4d4/0x850 net/socket.c:1285
>  prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
>  syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
>  do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
>  sock_create net/socket.c:1325 [inline]
>  SYSC_socket net/socket.c:1355 [inline]
>  SyS_socket+0xeb/0x1d0 net/socket.c:1335
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

[Eric Biggers]

On Tue, Jan 02, 2018 at 03:58:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6dc95bddc6976b800...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
> cookies.  Check SNMP counters.
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in tcp_v6_syn_recv_sock+0x628/0x23a0
> net/ipv6/tcp_ipv6.c:1144
> Write of size 160 at addr 8801cbdd7460 by task syzkaller545407/3196
> 
> CPU: 1 PID: 3196 Comm: syzkaller545407 Not tainted 4.15.0-rc5+ #241
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  tcp_v6_syn_recv_sock+0x628/0x23a0 net/ipv6/tcp_ipv6.c:1144
>  tcp_get_cookie_sock+0x102/0x540 net/ipv4/syncookies.c:213
>  cookie_v6_check+0x177d/0x2160 net/ipv6/syncookies.c:255
>  tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:1008 [inline]
>  tcp_v6_do_rcv+0xe4d/0x11c0 net/ipv6/tcp_ipv6.c:1316
>  tcp_v6_rcv+0x22ee/0x2b40 net/ipv6/tcp_ipv6.c:1510
>  ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>  dst_input include/net/dst.h:466 [inline]
>  ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ipv6_rcv+0xf1f/0x1f80 net/ipv6/ip6_input.c:208
>  __netif_receive_skb_core+0x1a3e/0x3450 net/core/dev.c:4461
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4526
>  process_backlog+0x203/0x740 net/core/dev.c:5205
>  napi_poll net/core/dev.c:5603 [inline]
>  net_rx_action+0x792/0x1910 net/core/dev.c:5669
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1115
>  
>  do_softirq.part.21+0x14d/0x190 kernel/softirq.c:329
>  do_softirq kernel/softirq.c:177 [inline]
>  __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>  ip6_finish_output2+0xba6/0x2390 net/ipv6/ip6_output.c:121
>  ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>  NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>  ip6_output+0x1eb/0x840 net/ipv6/ip6_output.c:163
>  dst_output include/net/dst.h:460 [inline]
>  NF_HOOK include/linux/netfilter.h:250 [inline]
>  ip6_xmit+0xd75/0x2080 net/ipv6/ip6_output.c:269
>  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>  __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>  tcp_send_fin+0x1b0/0xd20 net/ipv4/tcp_output.c:3087
>  tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2234
>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
>  sock_release+0x8d/0x1e0 net/socket.c:600
>  sock_close+0x16/0x20 net/socket.c:1129
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  get_signal+0x73f/0x16c0 kernel/signal.c:2335
>  do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
>  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x4456e9
> RSP: 002b:7fb4de631da8 EFLAGS: 0246 ORIG_RAX: 00ca
> RAX: fe00 RBX: 006dac3c RCX: 004456e9
> RDX:  RSI:  RDI: 006dac3c
> RBP:  R08:  R09: 

[PATCH RESEND net v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full.  This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:

precision 100 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0

Fix it by limiting option strings (combined name + value) to a much more
reasonable 128 bytes.  The exact limit is arbitrary, but currently the
only recognized option is formatted as "dnserror=%lu" which fits well
within this limit.

Also ratelimit the printks.

Reproducer:

perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver desc 
@s

This bug was found using syzkaller.

Reported-by: Mark Rutland <mark.rutl...@arm.com>
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/dns_resolver/dns_key.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 8396705deffc..40c851693f77 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
 
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
-   if (!opt_len) {
-   printk(KERN_WARNING
-  "Empty option to dns_resolver key\n");
+   if (opt_len <= 0 || opt_len > 128) {
+   pr_warn_ratelimited("Invalid option length (%d) 
for dns_resolver key\n",
+   opt_len);
return -EINVAL;
}
 
@@ -127,10 +127,8 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
}
 
bad_option_value:
-   printk(KERN_WARNING
-  "Option '%*.*s' to dns_resolver key:"
-  " bad/missing value\n",
-  opt_nlen, opt_nlen, opt);
+   pr_warn_ratelimited("Option '%*.*s' to dns_resolver 
key: bad/missing value\n",
+   opt_nlen, opt_nlen, opt);
return -EINVAL;
} while (opt = next_opt + 1, opt < end);
}
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Tue, Apr 17, 2018 at 02:24:37PM -0400, David Miller wrote:
> From: Eric Biggers <ebigge...@gmail.com>
> Date: Tue, 17 Apr 2018 11:23:40 -0700
> 
> > Can you queue this up for stable too?  syzbot has been hitting this on older
> > kernel versions.
> 
> If you want a patch bound for stable, it must show up in Linus's tree
> first which means you should target 'net' rather than 'net-next'.

Okay, can you move the patch there, or do I need to resend, or is it too late
already?  It's a clean cherry-pick.  Sorry, I'm not too familiar with the quirks
of net and netdev -- most other maintainers do things differently.

Thanks,

Eric

Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Tue, Apr 17, 2018 at 01:43:16PM -0400, David Miller wrote:
> From: Eric Biggers <ebigge...@gmail.com>
> Date: Mon, 16 Apr 2018 14:29:22 -0700
> 
> > From: Eric Biggers <ebigg...@google.com>
> > 
> > Adding a dns_resolver key whose payload contains a very long option name
> > resulted in that string being printed in full.  This hit the WARN_ONCE()
> > in set_precision() during the printk(), because printk() only supports a
> > precision of up to 32767 bytes:
> > 
> > precision 100 too large
> > WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
> > 
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > only recognized option is formatted as "dnserror=%lu" which fits well
> > within this limit.
> > 
> > Also ratelimit the printks.
> > 
> > Reproducer:
> > 
> > perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver 
> > desc @s
> > 
> > This bug was found using syzkaller.
> > 
> > Reported-by: Mark Rutland <mark.rutl...@arm.com>
> > Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that 
> > to be cached [ver #2]")
> > Signed-off-by: Eric Biggers <ebigg...@google.com>
> 
> Applied, thanks.

Can you queue this up for stable too?  syzbot has been hitting this on older
kernel versions.

Eric

[PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full.  This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:

precision 100 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0

Fix it by limiting option strings (combined name + value) to a much more
reasonable 128 bytes.  The exact limit is arbitrary, but currently the
only recognized option is formatted as "dnserror=%lu" which fits well
within this limit.

Also ratelimit the printks.

Reproducer:

perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver desc 
@s

This bug was found using syzkaller.

Reported-by: Mark Rutland <mark.rutl...@arm.com>
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/dns_resolver/dns_key.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 8396705deffc..40c851693f77 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
 
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
-   if (!opt_len) {
-   printk(KERN_WARNING
-  "Empty option to dns_resolver key\n");
+   if (opt_len <= 0 || opt_len > 128) {
+   pr_warn_ratelimited("Invalid option length (%d) 
for dns_resolver key\n",
+   opt_len);
return -EINVAL;
}
 
@@ -127,10 +127,8 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
}
 
bad_option_value:
-   printk(KERN_WARNING
-  "Option '%*.*s' to dns_resolver key:"
-  " bad/missing value\n",
-  opt_nlen, opt_nlen, opt);
+   pr_warn_ratelimited("Option '%*.*s' to dns_resolver 
key: bad/missing value\n",
+   opt_nlen, opt_nlen, opt);
return -EINVAL;
} while (opt = next_opt + 1, opt < end);
}
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Mon, Apr 02, 2018 at 12:20:35PM -0700, Eric Biggers wrote:
> On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> > On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > > > Eric Biggers <ebigge...@gmail.com> wrote:
> > > > 
> > > > > Fix it by limiting option strings (combined name + value) to a much 
> > > > > more
> > > > > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > > > > only recognized option is formatted as "dnserror=%lu" which fits well
> > > > > within this limit.
> > > > 
> > > > There will be more options coming ("ipv4", "ipv6") but they shouldn't 
> > > > overrun
> > > > this limit and we can always extend the limit if need be.
> > > > 
> > > > David
> > > 
> > > David (Howells) do you want to take this patch through the keyrings tree 
> > > or
> > > should I ask David Miller to take it through net-next?
> > > 
> > > Eric
> > 
> > Ping.
> 
> Ping again.

Times up.  I'll resend for net-next.

Eric

Re: KASAN: slab-out-of-bounds Read in pfkey_add

[Eric Biggers]

On Fri, Dec 15, 2017 at 11:51:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> audit: type=1400 audit(1513021744.055:7): avc:  denied  { map } for
> pid=3149 comm="syzkaller428285" path="/root/syzkaller428285483" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:341 [inline]
> BUG: KASAN: slab-out-of-bounds in pfkey_msg2xfrm_state net/key/af_key.c:1212
> [inline]
> BUG: KASAN: slab-out-of-bounds in pfkey_add+0x1634/0x3270
> net/key/af_key.c:1491
> Read of size 8192 at addr 8801c5197318 by task syzkaller428285/3149
> 
> CPU: 0 PID: 3149 Comm: syzkaller428285 Not tainted 4.15.0-rc3+ #127
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:341 [inline]
>  pfkey_msg2xfrm_state net/key/af_key.c:1212 [inline]
>  pfkey_add+0x1634/0x3270 net/key/af_key.c:1491
>  pfkey_process+0x60b/0x720 net/key/af_key.c:2809
>  pfkey_sendmsg+0x4d6/0x9f0 net/key/af_key.c:3648
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:646
>  ___sys_sendmsg+0x75b/0x8a0 net/socket.c:2026
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2060
>  C_SYSC_sendmsg net/compat.c:739 [inline]
>  compat_SyS_sendmsg+0x2a/0x40 net/compat.c:737
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> RIP: 0023:0xf7fd4c79
> RSP: 002b:ff9d7c1c EFLAGS: 0203 ORIG_RAX: 0172
> RAX: ffda RBX: 0003 RCX: 205f5000
> RDX:  RSI: 0167 RDI: 000f
> RBP: 0003 R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> 

Looks like this is going to be fixed by
https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length of
provided sadb_key"), but it's not applied yet to the ipsec tree yet.  Kevin, for
future reference, for syzbot bugs it would be helpful to reply to the original
bug report and say that a patch was sent out, or even better send the patch as a
reply to the bug report email, e.g.

git format-patch 
--in-reply-to="<001a114292fadd3e250560706...@google.com>"

for this one (and the Message ID can be found in the syzkaller-bugs archive even
if the email isn't in your inbox).  Otherwise people may not know that a patch
was sent out and do redundant work.  Thanks!

I also simplified the reproducer for this, so here it is just in case someone
wants it anyway:

#include 
#include 

int main()
{
int fd = socket(AF_KEY, SOCK_RAW, 2);
char msg[96] =

"\x02\x03\x00\x02\x0c\x00\x00\x00\x00\x00\x00\x01\x02\x00\x00\x00"

"\x03\x00\x05\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00"

"\x03\x00\x06\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00"

"\x02\x00\x01\x00\x00\x00\x00\x00\x00\x00\xfb\x00\x00\x00\x00\x00"

"\x02\x00\x08\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";

write(fd, msg, sizeof(msg));
}

It causes a 8192-byte out-of-bounds read.

Eric

Re: KASAN: use-after-free Read in inet_create

[Eric Biggers]

[+RDS list and maintainer]

On Sat, Dec 09, 2017 at 12:50:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> ==
> BUG: KASAN: use-after-free in inet_create+0xda0/0xf50 net/ipv4/af_inet.c:338
> Read of size 4 at addr 8801bde28554 by task kworker/u4:5/3492
> 
> CPU: 0 PID: 3492 Comm: kworker/u4:5 Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: krdsd rds_connect_worker
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
>  inet_create+0xda0/0xf50 net/ipv4/af_inet.c:338
>  __sock_create+0x4d4/0x850 net/socket.c:1265
>  sock_create_kern+0x3f/0x50 net/socket.c:1311
>  rds_tcp_conn_path_connect+0x26f/0x920 net/rds/tcp_connect.c:108
>  rds_connect_worker+0x156/0x1f0 net/rds/threads.c:165
>  process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> 
> Allocated by task 3362:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3548
>  kmem_cache_zalloc include/linux/slab.h:695 [inline]
>  net_alloc net/core/net_namespace.c:362 [inline]
>  copy_net_ns+0x196/0x580 net/core/net_namespace.c:402
>  create_new_namespaces+0x425/0x880 kernel/nsproxy.c:107
>  unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:206
>  SYSC_unshare kernel/fork.c:2421 [inline]
>  SyS_unshare+0x653/0xfa0 kernel/fork.c:2371
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 35:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kmem_cache_free+0x77/0x280 mm/slab.c:3750
>  net_free+0xca/0x110 net/core/net_namespace.c:378
>  net_drop_ns.part.11+0x26/0x30 net/core/net_namespace.c:385
>  net_drop_ns net/core/net_namespace.c:384 [inline]
>  cleanup_net+0x895/0xb60 net/core/net_namespace.c:502
>  process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> 
> The buggy address belongs to the object at 8801bde28080
>  which belongs to the cache net_namespace of size 6272
> The buggy address is located 1236 bytes inside of
>  6272-byte region [8801bde28080, 8801bde29900)
> The buggy address belongs to the page:
> page:df6a4dc0 count:1 mapcount:0 mapping:553659f1 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc008100(slab|head)
> raw: 02fffc008100 8801bde28080  00010001
> raw: ea0006f75da0 ea0006f60220 8801d989fe00 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801bde28400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801bde28480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > 8801bde28500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ^
>  8801bde28580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801bde28600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
> 

This is still happening regularly, though syzbot hasn't been able to generate a
reproducer yet.  All the reports seem to involve 

Re: BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()

[Eric Biggers]

On Thu, Jan 18, 2018 at 01:34:02AM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on linux-next commit
> a362f6d2cdbd089dd7040ba66dcb0ad276a20cf7 (Thu Jan 18 07:07:54 2018 +)
> Add linux-next specific files for 20180118
> 
> So far this crash happened 185 times on linux-next, mmots, net-next,
> upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by:
> syzbot+3ca02e1a9272a28e8959b32039154c5605164...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed.
> 
> BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 6246 Comm: syzkaller158939 Not tainted 4.15.0-rc8-next-20180118+
> #100
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  tfrc_rx_hist_sample_rtt+0x407/0x4d0 net/dccp/ccids/lib/packet_history.c:422
>  ccid3_hc_rx_packet_recv+0x696/0xeb3 net/dccp/ccids/ccid3.c:765
>  ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
>  dccp_deliver_input_to_ccids+0xd9/0x250 net/dccp/input.c:180
>  dccp_rcv_established+0x88/0xb0 net/dccp/input.c:378
>  dccp_v4_do_rcv+0x135/0x160 net/dccp/ipv4.c:653
>  sk_backlog_rcv include/net/sock.h:908 [inline]
>  __sk_receive_skb+0x33e/0xc10 net/core/sock.c:513
>  dccp_v4_rcv+0xf5f/0x1c80 net/dccp/ipv4.c:874
>  ip_local_deliver_finish+0x2f1/0xc50 net/ipv4/ip_input.c:216
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257
>  dst_input include/net/dst.h:449 [inline]
>  ip_rcv_finish+0x953/0x1e30 net/ipv4/ip_input.c:397
>  NF_HOOK include/linux/netfilter.h:288 [inline]
>  ip_rcv+0xc5a/0x1840 net/ipv4/ip_input.c:493
>  __netif_receive_skb_core+0x1a41/0x3460 net/core/dev.c:4537
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4602
>  process_backlog+0x203/0x740 net/core/dev.c:5282
>  napi_poll net/core/dev.c:5680 [inline]
>  net_rx_action+0x792/0x1910 net/core/dev.c:5746
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1150
>  
>  do_softirq.part.19+0x14d/0x190 kernel/softirq.c:329
>  do_softirq kernel/softirq.c:177 [inline]
>  __local_bh_enable_ip+0x1ee/0x230 kernel/softirq.c:182
>  local_bh_enable include/linux/bottom_half.h:32 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
>  ip_finish_output2+0x962/0x1550 net/ipv4/ip_output.c:231
>  ip_finish_output+0x864/0xd10 net/ipv4/ip_output.c:317
>  NF_HOOK_COND include/linux/netfilter.h:277 [inline]
>  ip_output+0x1d2/0x860 net/ipv4/ip_output.c:405
>  dst_output include/net/dst.h:443 [inline]
>  ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
>  ip_queue_xmit+0x8c0/0x18e0 net/ipv4/ip_output.c:504
>  dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142
>  dccp_xmit_packet+0x215/0x740 net/dccp/output.c:281
>  dccp_write_xmit+0x17d/0x1d0 net/dccp/output.c:363
>  dccp_sendmsg+0x95f/0xdc0 net/dccp/proto.c:813
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  ___sys_sendmsg+0x767/0x8b0 net/socket.c:2020
>  __sys_sendmsg+0xe5/0x210 net/socket.c:2054
>  SYSC_sendmsg net/socket.c:2065 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2061
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x446469
> RSP: 002b:7fcecb23bda8 EFLAGS: 0293 ORIG_RAX: 002e
> RAX: ffda RBX: 006dbc3c RCX: 00446469
> RDX: 0080 RSI: 206c8000 RDI: 0005
> RBP: 006dbc38 R08:  R09: 
> R10:  R11: 0293 R12: f8e4cbe49e572d45
> R13: 54c1b85d98aba1df R14: a6eaa24dbeb18c29 R15: 000c
> 

This is still happening.  It *might* be related to the other bug "suspicious RCU
usage at ./include/net/inet_sock.h:LINE".  Here's a simplified reproducer for
this one:

#include 
#include 
#include 
#include 
#include 

int main()
{
struct sockaddr_in addr = { .sin_family = AF_INET };
socklen_t addrlen = sizeof(addr);
int fd;

while (fork())
wait(NULL);
fd = socket(AF_INET, SOCK_DCCP, 0);
bind(fd, (void *), addrlen);
getsockname(fd, (void *), );
listen(fd, 100);
if (fork()) {
fd = socket(AF_INET, SOCK_DCCP, 0);
setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_CCID, "\x03", 1);
connect(fd, (void *), sizeof(addr));
} else {
fd = accept(fd, NULL, 0);
}
for (int i = 0; i < 1000; i++)
write(fd, "X", 1);
}

Re: WARNING in skb_warn_bad_offload

[Eric Biggers]

On Wed, Nov 01, 2017 at 09:50:18PM +0300, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Wed, Nov 1, 2017 at 9:48 PM, syzbot
> 
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 720bbe532b7c8f5613b48dea627fc58ed9ace707
> > git://git.cmpxchg.org/linux-mmots.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> 
> 
> This also happens on more recent commits, including linux-next
> 36ef71cae353f88fd6e095e2aaa3e5953af1685d (Oct 20):
> 
> syz0: caps=(0x040058c1, 0x) len=4203
> data_len=2810 gso_size=8465 gso_type=3 ip_summed=0
> [ cut here ]
> WARNING: CPU: 0 PID: 3473 at net/core/dev.c:2618
> skb_warn_bad_offload.cold.139+0x224/0x261 net/core/dev.c:2613
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 0 PID: 3473 Comm: a.out Not tainted 4.14.0-rc5-next-20171018 #15
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1a8/0x272 lib/dump_stack.c:52
>  panic+0x21e/0x4b7 kernel/panic.c:183
>  __warn.cold.6+0x182/0x187 kernel/panic.c:546
>  report_bug+0x232/0x330 lib/bug.c:183
>  fixup_bug+0x3f/0x90 arch/x86/kernel/traps.c:177
>  do_trap_no_signal arch/x86/kernel/traps.c:211 [inline]
>  do_trap+0x132/0x280 arch/x86/kernel/traps.c:260
>  do_error_trap+0x11f/0x390 arch/x86/kernel/traps.c:297
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310
>  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> RIP: 0010:skb_warn_bad_offload.cold.139+0x224/0x261 net/core/dev.c:2613
> RSP: 0018:880064797038 EFLAGS: 00010286
> RAX: 006f RBX: 88006365efe8 RCX: 
> RDX: 006f RSI: 815c88c1 RDI: ed000c8f2dfd
> RBP: 880064797090 R08: 8800686f86c0 R09: 0002
> R10: 8800686f86c0 R11:  R12: 8800538b1680
> R13:  R14: 8800538b1680 R15: 2111
>  __skb_gso_segment+0x69e/0x860 net/core/dev.c:2824
>  skb_gso_segment include/linux/netdevice.h:3971 [inline]
>  validate_xmit_skb+0x29f/0xca0 net/core/dev.c:3074
>  validate_xmit_skb_list+0xb7/0x120 net/core/dev.c:3125
>  sch_direct_xmit+0x5b5/0x710 net/sched/sch_generic.c:181
>  __dev_xmit_skb net/core/dev.c:3206 [inline]
>  __dev_queue_xmit+0x1e41/0x2350 net/core/dev.c:3473
>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3538
>  packet_snd net/packet/af_packet.c:2956 [inline]
>  packet_sendmsg+0x487a/0x64b0 net/packet/af_packet.c:2981
>  sock_sendmsg_nosec net/socket.c:632 [inline]
>  sock_sendmsg+0xd2/0x120 net/socket.c:642
>  ___sys_sendmsg+0x7cc/0x900 net/socket.c:2048
>  __sys_sendmsg+0xe6/0x220 net/socket.c:2082
>  SYSC_sendmsg net/socket.c:2093 [inline]
>  SyS_sendmsg+0x36/0x60 net/socket.c:2089
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x44bab9
> RSP: 002b:007eff18 EFLAGS: 0246 ORIG_RAX: 002e
> RAX: ffda RBX: 20001046 RCX: 0044bab9
> RDX: 4010 RSI: 207fcfc8 RDI: 0004
> RBP: 0086 R08: 850b2da14d2a3706 R09: 
> R10: 1b91126b7f398aaa R11: 0246 R12: 
> R13: 00407950 R14: 004079e0 R15: 
> 
> 
> 
> 
> 
> > [ cut here ]
> > WARNING: CPU: 0 PID: 2986 at net/core/dev.c:2585
> > skb_warn_bad_offload+0x2a9/0x380 net/core/dev.c:2580
> > Kernel panic - not syncing: panic_on_warn set ...
> >
> > CPU: 0 PID: 2986 Comm: syzkaller546001 Not tainted 4.13.0-mm1+ #7
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:16 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:52
> >  panic+0x1e4/0x417 kernel/panic.c:181
> >  __warn+0x1c4/0x1d9 kernel/panic.c:542
> >  report_bug+0x211/0x2d0 lib/bug.c:183
> >  fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> >  do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> >  do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> >  do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> >  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> >  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> > RIP: 0010:skb_warn_bad_offload+0x2a9/0x380 net/core/dev.c:2580
> > RSP: 0018:8801ce73f0a0 EFLAGS: 00010282
> > RAX: 006f RBX: 8801cd84cde0 RCX: 
> > RDX: 006f RSI: 110039ce7dd4 RDI: ed0039ce7e08
> > RBP: 8801ce73f0f8 R08: 8801ce73e790 R09: 
> > R10:  R11:  R12: 8801ce7802c0
> > R13:  R14: 8801ce7802c0 R15: 2111
> >  __skb_gso_segment+0x607/0x7f0 net/core/dev.c:2791
> 

Re: WARNING in kcm_exit_net (2)

[Eric Biggers]

On Wed, Nov 29, 2017 at 10:08:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 1d3b78bbc6e983fabb3fbf91b76339bf66e4a12c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> WARNING: CPU: 1 PID: 4099 at net/kcm/kcmsock.c:2014 kcm_exit_net+0x317/0x360
> net/kcm/kcmsock.c:2014
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 4099 Comm: kworker/u4:9 Not tainted 4.14.0+ #129
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: netns cleanup_net
> device lo entered promiscuous mode
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:926
> RIP: 0010:kcm_exit_net+0x317/0x360 net/kcm/kcmsock.c:2014
> RSP: :8801d9d27198 EFLAGS: 00010293
> RAX: 8801c0884540 RBX: 11003b3a4e33 RCX: 84a738e7
> RDX:  RSI: 0004 RDI: 0286
> RBP: 8801d9d27260 R08: 0003 R09: 11003b3a4e0c
> R10: 8801c0884540 R11: 0003 R12: 11003b3a4e37
> R13: 8801d9d27238 R14: 8801c5fec8a0 R15: 8801c4b62e40
>  ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
>  cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
>  process_one_work+0xbfd/0x1be0 kernel/workqueue.c:2112
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid

No reproducer, this last occurred on Dec 26 (103 days ago, commit fba961ab29e),
and there have been several potentially relevant KCM fixes since then such as
581e7226a5d ("kcm: Only allow TCP sockets to be attached to a KCM mux") and
e5571240236 ("kcm: Check if sk_user_data already set in kcm_attach").  So I am
invalidating this for syzbot, but if anyone thinks this may still be a bug then
feel free to look into it.

#syz invalid

Eric

Re: suspicious RCU usage at ./include/net/inet_sock.h:LINE

[Eric Biggers]

On Mon, Dec 25, 2017 at 05:45:00PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> fba961ab29e5ffb055592442808bb0f7962e05da
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> Can not set IPV6_FL_F_REFLECT if flowlabel_consistency sysctl is enable
> 
> =
> WARNING: suspicious RCU usage
> 4.15.0-rc4+ #164 Not tainted
> -
> ./include/net/inet_sock.h:136 suspicious rcu_dereference_check() usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by syzkaller667189/5780:
>  #0:  (sk_lock-AF_INET6){+.+.}, at: [<8d7d4e62>] lock_sock
> include/net/sock.h:1462 [inline]
>  #0:  (sk_lock-AF_INET6){+.+.}, at: [<8d7d4e62>]
> do_ipv6_setsockopt.isra.9+0x23d/0x38f0 net/ipv6/ipv6_sockglue.c:167
> 
> stack backtrace:
> CPU: 0 PID: 5780 Comm: syzkaller667189 Not tainted 4.15.0-rc4+ #164
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
>  ireq_opt_deref include/net/inet_sock.h:135 [inline]
>  inet_csk_route_req+0x824/0xca0 net/ipv4/inet_connection_sock.c:544
>  dccp_v4_send_response+0xa7/0x640 net/dccp/ipv4.c:485
>  dccp_v4_conn_request+0x9ee/0x11b0 net/dccp/ipv4.c:633
>  dccp_v6_conn_request+0xd30/0x1350 net/dccp/ipv6.c:317
>  dccp_rcv_state_process+0x574/0x1620 net/dccp/input.c:612
>  dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:682
>  dccp_v6_do_rcv+0x81a/0x9b0 net/dccp/ipv6.c:578
>  sk_backlog_rcv include/net/sock.h:907 [inline]
>  __release_sock+0x124/0x360 net/core/sock.c:2274
>  release_sock+0xa4/0x2a0 net/core/sock.c:2789
>  do_ipv6_setsockopt.isra.9+0x50f/0x38f0 net/ipv6/ipv6_sockglue.c:898
>  ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922
>  dccp_setsockopt+0x85/0xd0 net/dccp/proto.c:573
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
>  SYSC_setsockopt net/socket.c:1821 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1800
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x445ec9
> RSP: 002b:7fa001b58db8 EFLAGS: 0297 ORIG_RAX: 0036
> RAX: ffda RBX: 006dbc24 RCX: 00445ec9
> RDX: 0020 RSI: 0029 RDI: 0004
> RBP: 006dbc20 R08: 0020 R09: 
> R10: 2030a000 R11: 0297 R12: 
> R13: 7fff809eec1f R14: 7fa001b599c0 R15: 0001
> 
> =
> WARNING: suspicious RCU usage
> 4.15.0-rc4+ #164 Not tainted
> -
> ./include/net/inet_sock.h:136 suspicious rcu_dereference_check() usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by syzkaller667189/5780:
>  #0:  (sk_lock-AF_INET6){+.+.}, at: [<8d7d4e62>] lock_sock
> include/net/sock.h:1462 [inline]
>  #0:  (sk_lock-AF_INET6){+.+.}, at: [<8d7d4e62>]
> do_ipv6_setsockopt.isra.9+0x23d/0x38f0 net/ipv6/ipv6_sockglue.c:167
> 
> stack backtrace:
> CPU: 0 PID: 5780 Comm: syzkaller667189 Not tainted 4.15.0-rc4+ #164
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
>  ireq_opt_deref include/net/inet_sock.h:135 [inline]
>  dccp_v4_send_response+0x4b0/0x640 net/dccp/ipv4.c:496
>  dccp_v4_conn_request+0x9ee/0x11b0 net/dccp/ipv4.c:633
>  dccp_v6_conn_request+0xd30/0x1350 net/dccp/ipv6.c:317
>  dccp_rcv_state_process+0x574/0x1620 net/dccp/input.c:612
>  dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:682
>  dccp_v6_do_rcv+0x81a/0x9b0 net/dccp/ipv6.c:578
>  sk_backlog_rcv include/net/sock.h:907 [inline]
>  __release_sock+0x124/0x360 net/core/sock.c:2274
>  release_sock+0xa4/0x2a0 net/core/sock.c:2789
>  do_ipv6_setsockopt.isra.9+0x50f/0x38f0 net/ipv6/ipv6_sockglue.c:898
>  ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922
>  dccp_setsockopt+0x85/0xd0 net/dccp/proto.c:573
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
>  SYSC_setsockopt net/socket.c:1821 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1800
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x445ec9
> RSP: 002b:7fa001b58db8 EFLAGS: 0297 ORIG_RAX: 0036
> RAX: ffda RBX: 006dbc24 RCX: 00445ec9
> RDX: 0020 RSI: 0029 RDI: 0004
> RBP: 006dbc20 R08: 0020 R09: 

Re: KASAN: use-after-free Read in worker_thread (2)

[Eric Biggers]

On Sat, Nov 11, 2017 at 07:56:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> d9e0e63d9a6f88440eb201e1491fcf730272c706
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> BUG: KASAN: use-after-free in worker_thread+0x15bb/0x1990
> kernel/workqueue.c:2244
> Read of size 8 at addr 88002d0e3de0 by task kworker/u8:1/1209
> 
> CPU: 0 PID: 1209 Comm: kworker/u8:1 Not tainted 4.14.0-rc8-next-20171110+
> #12
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  worker_thread+0x15bb/0x1990 kernel/workqueue.c:2244
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437
> 
> Allocated by task 11866:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3548
>  kmem_cache_zalloc include/linux/slab.h:693 [inline]
>  kcm_attach net/kcm/kcmsock.c:1394 [inline]
>  kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
>  kcm_ioctl+0x2d1/0x1610 net/kcm/kcmsock.c:1695
>  sock_do_ioctl+0x65/0xb0 net/socket.c:960
>  sock_ioctl+0x2c2/0x440 net/socket.c:1057
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 11867:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kmem_cache_free+0x77/0x280 mm/slab.c:3750
>  kcm_unattach+0xe50/0x1510 net/kcm/kcmsock.c:1563
>  kcm_unattach_ioctl net/kcm/kcmsock.c:1608 [inline]
>  kcm_ioctl+0xdf0/0x1610 net/kcm/kcmsock.c:1705
>  sock_do_ioctl+0x65/0xb0 net/socket.c:960
>  sock_ioctl+0x2c2/0x440 net/socket.c:1057
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> The buggy address belongs to the object at 88002d0e3d00
>  which belongs to the cache kcm_psock_cache of size 576
> The buggy address is located 224 bytes inside of
>  576-byte region [88002d0e3d00, 88002d0e3f40)
> The buggy address belongs to the page:
> page:eab43880 count:1 mapcount:0 mapping:88002d0e2180 index:0x0
> compound_mapcount: 0
> flags: 0x1008100(slab|head)
> raw: 01008100 88002d0e2180  0001000b
> raw: eab14920 eab27e20 88002b0089c0 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  88002d0e3c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  88002d0e3d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > 88002d0e3d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>^
>  88002d0e3e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  88002d0e3e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==

No longer occurring, the fix seems to have been commit 7e9964574ee97:

#syz fix: kcm: Only allow TCP sockets to be attached to a KCM mux

- Eric

Re: [PATCH v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > > Eric Biggers <ebigge...@gmail.com> wrote:
> > > 
> > > > Fix it by limiting option strings (combined name + value) to a much more
> > > > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > > > only recognized option is formatted as "dnserror=%lu" which fits well
> > > > within this limit.
> > > 
> > > There will be more options coming ("ipv4", "ipv6") but they shouldn't 
> > > overrun
> > > this limit and we can always extend the limit if need be.
> > > 
> > > David
> > 
> > David (Howells) do you want to take this patch through the keyrings tree or
> > should I ask David Miller to take it through net-next?
> > 
> > Eric
> 
> Ping.

Ping again.

[PATCH] sunrpc: remove incorrect HMAC request initialization

[Eric Biggers]

make_checksum_hmac_md5() is allocating an HMAC transform and doing
crypto API calls in the following order:

crypto_ahash_init()
crypto_ahash_setkey()
crypto_ahash_digest()

This is wrong because it makes no sense to init() the request before a
key has been set, given that the initial state depends on the key.  And
digest() is short for init() + update() + final(), so in this case
there's no need to explicitly call init() at all.

Before commit 9fa68f620041 ("crypto: hash - prevent using keyed hashes
without setting key") the extra init() had no real effect, at least for
the software HMAC implementation.  (There are also hardware drivers that
implement HMAC-MD5, and it's not immediately obvious how gracefully they
handle init() before setkey().)  But now the crypto API detects this
incorrect initialization and returns -ENOKEY.  This is breaking NFS
mounts in some cases.

Fix it by removing the incorrect call to crypto_ahash_init().

Reported-by: Michael Young <m.a.yo...@durham.ac.uk>
Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting 
key")
Fixes: fffdaef2eb4a ("gss_krb5: Add support for rc4-hmac encryption")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c 
b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 12649c9fedab..8654494b4d0a 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -237,9 +237,6 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, 
int hdrlen,
 
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
-   err = crypto_ahash_init(req);
-   if (err)
-   goto out;
err = crypto_ahash_setkey(hmac_md5, cksumkey, kctx->gk5e->keylength);
if (err)
goto out;
-- 
2.17.0.rc1.321.gba9d0f2565-goog

Re: NFS mounts failing when keytab present on client

[Eric Biggers]

On Wed, Mar 28, 2018 at 11:46:28AM -0400, J. Bruce Fields wrote:
> On Tue, Mar 27, 2018 at 03:29:50PM -0700, Eric Biggers wrote:
> > Hi Michael,
> > 
> > On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> > > NFS mounts stopped working on one of my computers after a kernel update 
> > > from
> > > 4.15.3 to 4.15.4. I traced the problem to the commit
> > > [46e8d06e423c4f35eac7a8b677b713b3ec9b0684] crypto: hash - prevent using
> > > keyed hashes without setting key
> > > and a later kernel with this patch reverted works normally.
> > > 
> > > The problem seems to be related to kerberos as the mount fails when the
> > > keytab is present, but works if I rename the keytab file. This is true 
> > > even
> > > though the mount is with sec=sys . The mount should also work with 
> > > sec=krb5
> > > but that also fails in the same way. When the mount fails there are errors
> > > in dmesg like
> > > [ 1232.522816] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.522819] RPC: couldn't encode RPC header, exit EIO
> > > [ 1232.522856] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.522857] RPC: couldn't encode RPC header, exit EIO
> > > [ 1232.522863] NFS: nfs4_discover_server_trunking unhandled error -5.
> > > Exiting with error EIO
> > > [ 1232.525039] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.525042] RPC: couldn't encode RPC header, exit EIO
> > > 
> > >   Michael Young
> > 
> > Thanks for the bug report.  I think the error is coming from
> > net/sunrpc/auth_gss/gss_krb5_crypto.c.  There are two potential problems I 
> > see.
> > The first one, which is definitely a bug, is that make_checksum_hmac_md5()
> > allocates an HMAC transform and request, then does these crypto API calls:
> > 
> > crypto_ahash_init()
> > crypto_ahash_setkey()
> > crypto_ahash_digest()
> > 
> > This is wrong because it makes no sense to init() the HMAC request before 
> > the
> > key has been set, and doubly so when it's calling digest() which is 
> > shorthand
> > for init() + update() + final().  So I think it just needs to be removed.  
> > You
> > can test the following patch:
> 
> When was this introduced? 
> 
> 3b5cf20cf439 "sunrpc: Use skcipher and ahash/shash"
>   - probably not, assuming the above was still just as wrong with
> crypto_hash_{init,setkey,digest} as it is with
> crypto_ahash_{init,setkey,digest}
> 
> So I'm guessing it was wrong from the start when it was added by
> fffdaef2eb4a "gss_krb5: Add support for rc4-hmac encryption" 8 years
> ago.  Wonder why it took this long to notice?  Did something else
> change?
> 
> --b.

It was wrong from the start, but the crypto API only recently started enforcing
that the key has to be set before init() or digest() is called.  Before that the
code was just doing unnecessary work, at least with the software HMAC
implementation.  Though, there are also hardware crypto drivers that implement
HMAC-MD5, and it's not immediately obvious that they handle init() before
setkey() as gracefully as the software implementation.

Eric

Re: NFS mounts failing when keytab present on client

[Eric Biggers]

On Wed, Mar 28, 2018 at 09:00:14AM +0100, M A Young wrote:
> On Tue, 27 Mar 2018, Eric Biggers wrote:
> 
> > Hi Michael,
> > 
> > On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> > > NFS mounts stopped working on one of my computers after a kernel update 
> > > from
> > > 4.15.3 to 4.15.4. I traced the problem to the commit
> > > [46e8d06e423c4f35eac7a8b677b713b3ec9b0684] crypto: hash - prevent using
> > > keyed hashes without setting key
> > > and a later kernel with this patch reverted works normally.
> > > 
> > > The problem seems to be related to kerberos as the mount fails when the
> > > keytab is present, but works if I rename the keytab file. This is true 
> > > even
> > > though the mount is with sec=sys . The mount should also work with 
> > > sec=krb5
> > > but that also fails in the same way. When the mount fails there are errors
> > > in dmesg like
> > > [ 1232.522816] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.522819] RPC: couldn't encode RPC header, exit EIO
> > > [ 1232.522856] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.522857] RPC: couldn't encode RPC header, exit EIO
> > > [ 1232.522863] NFS: nfs4_discover_server_trunking unhandled error -5.
> > > Exiting with error EIO
> > > [ 1232.525039] gss_marshal: gss_get_mic FAILED (851968)
> > > [ 1232.525042] RPC: couldn't encode RPC header, exit EIO
> > > 
> > >   Michael Young
> > 
> > Thanks for the bug report.  I think the error is coming from
> > net/sunrpc/auth_gss/gss_krb5_crypto.c.  There are two potential problems I 
> > see.
> > The first one, which is definitely a bug, is that make_checksum_hmac_md5()
> > allocates an HMAC transform and request, then does these crypto API calls:
> > 
> > crypto_ahash_init()
> > crypto_ahash_setkey()
> > crypto_ahash_digest()
> > 
> > This is wrong because it makes no sense to init() the HMAC request before 
> > the
> > key has been set, and doubly so when it's calling digest() which is 
> > shorthand
> > for init() + update() + final().  So I think it just needs to be removed.  
> > You
> > can test the following patch:
> > 
> > diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c 
> > b/net/sunrpc/auth_gss/gss_krb5_crypto.c
> > index 12649c9fedab..8654494b4d0a 100644
> > --- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
> > +++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
> > @@ -237,9 +237,6 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char 
> > *header, int hdrlen,
> >  
> > ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, 
> > NULL);
> >  
> > -   err = crypto_ahash_init(req);
> > -   if (err)
> > -   goto out;
> > err = crypto_ahash_setkey(hmac_md5, cksumkey, 
> > kctx->gk5e->keylength);
> > if (err)
> > goto out;
> > 
> > If that's not it, it's also possible that the error is coming from the
> > crypto_ahash_init() in make_checksum().  That can only happen if 'cksumkey' 
> > is
> > NULL and the hash algorithm is keyed, which implies a logical error as it
> > doesn't make sense to use a keyed hash algorithm without the key.  The 
> > callers
> > do check kctx->gk5e->keyed_cksum which I'd hope would prevent this, though
> > perhaps kctx->cksum can be NULL.
> > 
> > Eric
> 
> The patch fixes the problem.
> 
>   Michael Young

Okay, thanks for testing!  I'll send a formal patch.

Eric

Re: NFS mounts failing when keytab present on client

[Eric Biggers]

Hi Michael,

On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> NFS mounts stopped working on one of my computers after a kernel update from
> 4.15.3 to 4.15.4. I traced the problem to the commit
> [46e8d06e423c4f35eac7a8b677b713b3ec9b0684] crypto: hash - prevent using
> keyed hashes without setting key
> and a later kernel with this patch reverted works normally.
> 
> The problem seems to be related to kerberos as the mount fails when the
> keytab is present, but works if I rename the keytab file. This is true even
> though the mount is with sec=sys . The mount should also work with sec=krb5
> but that also fails in the same way. When the mount fails there are errors
> in dmesg like
> [ 1232.522816] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.522819] RPC: couldn't encode RPC header, exit EIO
> [ 1232.522856] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.522857] RPC: couldn't encode RPC header, exit EIO
> [ 1232.522863] NFS: nfs4_discover_server_trunking unhandled error -5.
> Exiting with error EIO
> [ 1232.525039] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.525042] RPC: couldn't encode RPC header, exit EIO
> 
>   Michael Young

Thanks for the bug report.  I think the error is coming from
net/sunrpc/auth_gss/gss_krb5_crypto.c.  There are two potential problems I see.
The first one, which is definitely a bug, is that make_checksum_hmac_md5()
allocates an HMAC transform and request, then does these crypto API calls:

crypto_ahash_init()
crypto_ahash_setkey()
crypto_ahash_digest()

This is wrong because it makes no sense to init() the HMAC request before the
key has been set, and doubly so when it's calling digest() which is shorthand
for init() + update() + final().  So I think it just needs to be removed.  You
can test the following patch:

diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c 
b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 12649c9fedab..8654494b4d0a 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -237,9 +237,6 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, 
int hdrlen,
 
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
-   err = crypto_ahash_init(req);
-   if (err)
-   goto out;
err = crypto_ahash_setkey(hmac_md5, cksumkey, kctx->gk5e->keylength);
if (err)
goto out;

If that's not it, it's also possible that the error is coming from the
crypto_ahash_init() in make_checksum().  That can only happen if 'cksumkey' is
NULL and the hash algorithm is keyed, which implies a logical error as it
doesn't make sense to use a keyed hash algorithm without the key.  The callers
do check kctx->gk5e->keyed_cksum which I'd hope would prevent this, though
perhaps kctx->cksum can be NULL.

Eric

Re: [PATCH v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > Eric Biggers <ebigge...@gmail.com> wrote:
> > 
> > > Fix it by limiting option strings (combined name + value) to a much more
> > > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > > only recognized option is formatted as "dnserror=%lu" which fits well
> > > within this limit.
> > 
> > There will be more options coming ("ipv4", "ipv6") but they shouldn't 
> > overrun
> > this limit and we can always extend the limit if need be.
> > 
> > David
> 
> David (Howells) do you want to take this patch through the keyrings tree or
> should I ask David Miller to take it through net-next?
> 
> Eric

Ping.

Re: [PATCH net] kcm: lock lower socket in kcm_attach

[Eric Biggers]

On Mon, Mar 12, 2018 at 02:25:41PM -0700, Tom Herbert wrote:
> On Mon, Mar 12, 2018 at 2:09 PM, Eric Biggers <ebigge...@gmail.com> wrote:
> > On Mon, Mar 12, 2018 at 02:04:12PM -0700, Tom Herbert wrote:
> >> Need to lock lower socket in order to provide mutual exclusion
> >> with kcm_unattach.
> >>
> >> Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor 
> >> module")
> >> Signed-off-by: Tom Herbert <t...@quantonium.net>
> >> ---
> >
> > Is this fixing the syzbot-reported bug "KASAN: use-after-free Read in
> > get_work_pool"?  If so, please add:
> >
> > Reported-by: 
> > syzbot+ea75c0ffcd353d32515f064aaebefc5279e61...@syzkaller.appspotmail.com
> 
> Yeah, I was looking for a "reported by". I didn't see it in the email
> from syzbot. Where is this found?
> 
> Thanks,
> Tom

This was an old bug report that was sent out before syzbot was updated to
suggest a Reported-by line.  But you can still use Reported-by for these old
bugs.  I took the bug ID from the From: header of the email.

Eric

Re: [PATCH net] kcm: lock lower socket in kcm_attach

[Eric Biggers]

On Mon, Mar 12, 2018 at 02:04:12PM -0700, Tom Herbert wrote:
> Need to lock lower socket in order to provide mutual exclusion
> with kcm_unattach.
> 
> Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor module")
> Signed-off-by: Tom Herbert 
> ---

Is this fixing the syzbot-reported bug "KASAN: use-after-free Read in
get_work_pool"?  If so, please add:

Reported-by: 
syzbot+ea75c0ffcd353d32515f064aaebefc5279e61...@syzkaller.appspotmail.com

Re: [PATCH v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> Eric Biggers <ebigge...@gmail.com> wrote:
> 
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > only recognized option is formatted as "dnserror=%lu" which fits well
> > within this limit.
> 
> There will be more options coming ("ipv4", "ipv6") but they shouldn't overrun
> this limit and we can always extend the limit if need be.
> 
> David

David (Howells) do you want to take this patch through the keyrings tree or
should I ask David Miller to take it through net-next?

Eric

Re: KASAN: use-after-free Read in get_work_pool

[Eric Biggers]

On Wed, Feb 14, 2018 at 02:45:05PM +0100, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Wed, Dec 6, 2017 at 1:50 PM, Dmitry Vyukov  wrote:
> > On Fri, Oct 27, 2017 at 11:18 PM, Cong Wang  
> > wrote:
> >> On Thu, Oct 26, 2017 at 11:00 PM, Dmitry Vyukov  wrote:
> >>> On Thu, Oct 26, 2017 at 7:58 PM, Tejun Heo  wrote:
>  Hello,
> 
>  On Thu, Oct 26, 2017 at 09:35:44AM -0700, syzbot wrote:
> > BUG: KASAN: use-after-free in __read_once_size
> > include/linux/compiler.h:276 [inline]
> > BUG: KASAN: use-after-free in atomic64_read
> > arch/x86/include/asm/atomic64_64.h:21 [inline]
> > BUG: KASAN: use-after-free in atomic_long_read
> > include/asm-generic/atomic-long.h:44 [inline]
> > BUG: KASAN: use-after-free in get_work_pool+0x1c2/0x1e0
> > kernel/workqueue.c:709
> > Read of size 8 at addr 8801cc58c378 by task syz-executor5/21326
> >
> > CPU: 1 PID: 21326 Comm: syz-executor5 Not tainted 4.13.0+ #43
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:16 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:52
> >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >  kasan_report_error mm/kasan/report.c:351 [inline]
> >  kasan_report+0x24e/0x340 mm/kasan/report.c:409
> >  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> >  __read_once_size include/linux/compiler.h:276 [inline]
> >  atomic64_read arch/x86/include/asm/atomic64_64.h:21 [inline]
> >  atomic_long_read include/asm-generic/atomic-long.h:44 [inline]
> >  get_work_pool+0x1c2/0x1e0 kernel/workqueue.c:709
> >  __queue_work+0x235/0x1150 kernel/workqueue.c:1401
> >  queue_work_on+0x16a/0x1c0 kernel/workqueue.c:1486
> >  queue_work include/linux/workqueue.h:489 [inline]
> >  strp_check_rcv+0x25/0x30 net/strparser/strparser.c:553
> >  kcm_attach net/kcm/kcmsock.c:1439 [inline]
> >  kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
> >  kcm_ioctl+0x826/0x1610 net/kcm/kcmsock.c:1695
> >  sock_do_ioctl+0x65/0xb0 net/socket.c:961
> >  sock_ioctl+0x2c2/0x440 net/socket.c:1058
> >  vfs_ioctl fs/ioctl.c:45 [inline]
> >  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:685
> >  SYSC_ioctl fs/ioctl.c:700 [inline]
> >  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
> >  entry_SYSCALL_64_fastpath+0x1f/0xbe
> 
>  Looks like kcm is trying to reuse a work item whose last workqueue has
>  been destroyed without re-initing it.  A work item needs to be
>  reinit'd.
> >>>
> >>> +kcm maintainers
> >>
> >> Can you try the fix below? There is no C reproducer so I can't verify it.
> >
> >
> > Hi Cong,
> >
> > syzbot can now test proposed patches, see
> > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
> > for details. Please give it a try.
> >
> >> diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
> >> index af4e76ac88ff..7816f44c576a 100644
> >> --- a/net/kcm/kcmsock.c
> >> +++ b/net/kcm/kcmsock.c
> >> @@ -1433,11 +1433,12 @@ static int kcm_attach(struct socket *sock,
> >> struct socket *csock,
> >> KCM_STATS_INCR(mux->stats.psock_attach);
> >> mux->psocks_cnt++;
> >> psock_now_avail(psock);
> >> -   spin_unlock_bh(>lock);
> >>
> >> /* Schedule RX work in case there are already bytes queued */
> >> strp_check_rcv(>strp);
> >>
> >> +   spin_unlock_bh(>lock);
> >> +
> >> return 0;
> >>  }
> 
> 
> Hi Cong,
> 
> Was this ever merged? Is it still necessary?
> 

syzbot is no longer hitting this bug for some reason but it's still there.  Tom,
it looks like you wrote the buggy code (it's yet another KCM bug, apparently);
can you please look into it?

I've put together a C reproducer that works on latest linux-next (next-20180309,
commit 61530b14b059d).  It works as an unprivileged user provided that KCM is
enabled, and that KASAN is enabled so you see the use-after-free report:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
union bpf_attr prog = {
.prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
.insn_cnt = 2,
.insns = (__u64)(__u64[]){ 0xb7, 0x95 },
.license = (__u64)"",
};
int tcp_fd, bpf_fd, kcm_fd;
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_port = __constant_htons(3270),
.sin_addr = { __constant_htonl(0x7f01) }
};

tcp_fd = socket(AF_INET, SOCK_STREAM, 0);
bind(tcp_fd, (void *), sizeof(addr));
listen(tcp_fd, 1);
tcp_fd = socket(AF_INET, SOCK_STREAM, 0);
connect(tcp_fd, (void *), sizeof(addr));
bpf_fd = syscall(__NR_bpf, BPF_PROG_LOAD, , 48);
kcm_fd = socket(AF_KCM, 

Re: KASAN: use-after-free Read in strp_data_ready

[Eric Biggers]

On Tue, 24 Oct 2017 08:15:01 -0700, syzbot wrote:
> Hello, 
> 
> syzkaller hit the following crash on   
> b9f1f1ce866c28e3d9b86202441b220244754a69 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master 
> compiler: gcc (GCC) 7.1.1 20170620 
> .config is attached 
> Raw console output is attached. 
> C reproducer is attached 
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ 
> for information about syzkaller reproducers 
> 
> 
> device lo entered promiscuous mode 
> == 
> BUG: KASAN: use-after-free in strp_data_ready+0x2fb/0x390   
> net/strparser/strparser.c:394 
> Read of size 1 at addr 8801cebdda50 by task syzkaller825731/2994 
> 
> CPU: 1 PID: 2994 Comm: syzkaller825731 Not tainted 4.14.0-rc4+ #82 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS   
> Google 01/01/2011 
> Call Trace: 
>
>   __dump_stack lib/dump_stack.c:16 [inline] 
>   dump_stack+0x194/0x257 lib/dump_stack.c:52 
>   print_address_description+0x73/0x250 mm/kasan/report.c:252 
>   kasan_report_error mm/kasan/report.c:351 [inline] 
>   kasan_report+0x25b/0x340 mm/kasan/report.c:409 
>   __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427 
>   strp_data_ready+0x2fb/0x390 net/strparser/strparser.c:394 
>   psock_data_ready+0x56/0x70 net/kcm/kcmsock.c:353 
>   tcp_data_queue+0x1da8/0x3e50 net/ipv4/tcp_input.c:4672 
>   tcp_rcv_established+0x844/0x18a0 net/ipv4/tcp_input.c:5496 
>   tcp_v4_do_rcv+0x2ab/0x7d0 net/ipv4/tcp_ipv4.c:1460 
>   tcp_v4_rcv+0x24e5/0x2f80 net/ipv4/tcp_ipv4.c:1721 
>   ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216 
>   NF_HOOK include/linux/netfilter.h:249 [inline] 
>   ip_local_deliver+0x1ce/0x6e0 net/ipv4/ip_input.c:257 
>   dst_input include/net/dst.h:465 [inline] 
>   ip_rcv_finish+0x887/0x19a0 net/ipv4/ip_input.c:397 
>   NF_HOOK include/linux/netfilter.h:249 [inline] 
>   ip_rcv+0xc3f/0x1820 net/ipv4/ip_input.c:493 
>   __netif_receive_skb_core+0x1a3e/0x34b0 net/core/dev.c:4477 
>   __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4542 
>   process_backlog+0x203/0x740 net/core/dev.c:5221 
>   napi_poll net/core/dev.c:5619 [inline] 
>   net_rx_action+0x792/0x1910 net/core/dev.c:5685 
>   __do_softirq+0x29d/0xbb2 kernel/softirq.c:284 
>   do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:957 
>
>   do_softirq.part.20+0x14d/0x190 kernel/softirq.c:328 
>   do_softirq kernel/softirq.c:176 [inline] 
>   __local_bh_enable_ip+0x135/0x160 kernel/softirq.c:181 
>   local_bh_enable include/linux/bottom_half.h:31 [inline] 
>   rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline] 
>   ip_finish_output2+0x8ad/0x1460 net/ipv4/ip_output.c:231 
>   ip_finish_output+0x85e/0xd10 net/ipv4/ip_output.c:317 
>   NF_HOOK_COND include/linux/netfilter.h:238 [inline] 
>   ip_output+0x1cc/0x860 net/ipv4/ip_output.c:405 
>   dst_output include/net/dst.h:459 [inline] 
>   ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 
>   ip_queue_xmit+0x8c6/0x18e0 net/ipv4/ip_output.c:504 
>   tcp_transmit_skb+0x1ab7/0x3840 net/ipv4/tcp_output.c:1137 
>   tcp_write_xmit+0x663/0x4de0 net/ipv4/tcp_output.c:2341 
>   __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2513 
>   tcp_send_fin+0x1b0/0xdb0 net/ipv4/tcp_output.c:3058 
>   tcp_close+0xbe0/0xfc0 net/ipv4/tcp.c:2232 
>   inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426 
>   sock_release+0x8d/0x1e0 net/socket.c:597 
>   sock_close+0x16/0x20 net/socket.c:1126 
>   __fput+0x333/0x7f0 fs/file_table.c:210 
>   fput+0x15/0x20 fs/file_table.c:244 
>   task_work_run+0x199/0x270 kernel/task_work.c:112 
>   exit_task_work include/linux/task_work.h:21 [inline] 
>   do_exit+0x9d2/0x1af0 kernel/exit.c:865 
> 
> 
> --- 
> This bug is generated by a dumb bot. It may contain errors. 
> See https://goo.gl/tpsmEJ for details. 
> Direct all questions to syzk...@googlegroups.com. 
> 
> syzbot will keep track of this bug report. 
> Once a fix for this bug is committed, please reply to this email with: 
> #syz fix: exact-commit-title 
> To mark this as a duplicate of another syzbot report, please reply with:

While unfortunately this bug report was ignored, it seems it was eventually
reported as a slightly different use-after-free ("KASAN: use-after-free Read in
psock_write_space") and was fixed around Jan 25 by commit 581e7226a5d4.
So telling syzbot:

#syz fix: kcm: Only allow TCP sockets to be attached to a KCM mux

- Eric

[PATCH v2] KEYS: DNS: limit the length of option strings

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full.  This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:

precision 100 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0

Fix it by limiting option strings (combined name + value) to a much more
reasonable 128 bytes.  The exact limit is arbitrary, but currently the
only recognized option is formatted as "dnserror=%lu" which fits well
within this limit.

Also ratelimit the printks.

Reproducer:

perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver desc 
@s

This bug was found using syzkaller.

Reported-by: Mark Rutland <mark.rutl...@arm.com>
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Cc: <sta...@vger.kernel.org> # v2.6.36+
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/dns_resolver/dns_key.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index e1d4d898a007..ed372d550137 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
 
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
-   if (!opt_len) {
-   printk(KERN_WARNING
-  "Empty option to dns_resolver key\n");
+   if (opt_len <= 0 || opt_len > 128) {
+   pr_warn_ratelimited("Invalid option length (%d) 
for dns_resolver key\n",
+   opt_len);
return -EINVAL;
}
 
@@ -127,10 +127,8 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
}
 
bad_option_value:
-   printk(KERN_WARNING
-  "Option '%*.*s' to dns_resolver key:"
-  " bad/missing value\n",
-  opt_nlen, opt_nlen, opt);
+   pr_warn_ratelimited("Option '%*.*s' to dns_resolver 
key: bad/missing value\n",
+   opt_nlen, opt_nlen, opt);
return -EINVAL;
} while (opt = next_opt + 1, opt < end);
}
-- 
2.16.2.395.g2e18187dfd-goog

Re: [PATCH] KEYS: DNS: limit the length of option strings

[Eric Biggers]

On Tue, Feb 27, 2018 at 06:34:19PM -0800, Eric Dumazet wrote:
> On Tue, 2018-02-27 at 17:49 -0800, Eric Biggers wrote:
> > From: Eric Biggers <ebigg...@google.com>
> > 
> > Adding a dns_resolver key whose payload contains a very long option name
> > resulted in that string being printed in full.  This hit the WARN_ONCE()
> > in set_precision() during the printk(), because printk() only supports a
> > precision of up to 32767 bytes:
> > 
> > precision 100 too large
> > WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
> > 
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes.  The exact limit is arbitrary, but currently the
> > only recognized option is formatted as "dnserror=%lu" which fits well
> > within this limit.
> > 
> > Reproducer:
> > 
> > perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver 
> > desc @s
> > 
> > This bug was found using syzkaller.
> > 
> > Reported-by: Mark Rutland <mark.rutl...@arm.com>
> > Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that 
> > to be cached [ver #2]")
> > Cc: <sta...@vger.kernel.org> # v2.6.36+
> > Signed-off-by: Eric Biggers <ebigg...@google.com>
> > ---
> >  net/dns_resolver/dns_key.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
> > index e1d4d898a007..7c0aae2e512d 100644
> > --- a/net/dns_resolver/dns_key.c
> > +++ b/net/dns_resolver/dns_key.c
> > @@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
> >  
> > next_opt = memchr(opt, '#', end - opt) ?: end;
> > opt_len = next_opt - opt;
> > -   if (!opt_len) {
> > -   printk(KERN_WARNING
> > -  "Empty option to dns_resolver key\n");
> > +   if (opt_len <= 0 || opt_len > 128) {
> > +   pr_warn("Invalid option length (%d) for 
> > dns_resolver key\n",
> > +   opt_len);
> 
> If a bot can harass us here, then pr_warn_ratelimited would be nice ?
> 

I guess we might as well.  But there is another user-triggerable printk just
below, so I'll need to change that one too.  I'll send out v2.

Eric

[PATCH] KEYS: DNS: limit the length of option strings

[Eric Biggers]

From: Eric Biggers <ebigg...@google.com>

Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full.  This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:

precision 100 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0

Fix it by limiting option strings (combined name + value) to a much more
reasonable 128 bytes.  The exact limit is arbitrary, but currently the
only recognized option is formatted as "dnserror=%lu" which fits well
within this limit.

Reproducer:

perl -e 'print "#", "A" x 100, "\x00"' | keyctl padd dns_resolver desc 
@s

This bug was found using syzkaller.

Reported-by: Mark Rutland <mark.rutl...@arm.com>
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be 
cached [ver #2]")
Cc: <sta...@vger.kernel.org> # v2.6.36+
Signed-off-by: Eric Biggers <ebigg...@google.com>
---
 net/dns_resolver/dns_key.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index e1d4d898a007..7c0aae2e512d 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
 
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
-   if (!opt_len) {
-   printk(KERN_WARNING
-  "Empty option to dns_resolver key\n");
+   if (opt_len <= 0 || opt_len > 128) {
+   pr_warn("Invalid option length (%d) for 
dns_resolver key\n",
+   opt_len);
return -EINVAL;
}
 
-- 
2.16.2.395.g2e18187dfd-goog

Re: dns_resolver_preparse tries to print arbitrarily-large user-provided strings

[Eric Biggers]

Hi Mark,

On Tue, Feb 27, 2018 at 04:43:13PM +, Mark Rutland wrote:
> Hi,
> 
> As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a
> system hang which I was able to minize to the reproducer below. It looks
> like the system hang is an artifact of Syzkaller using panic_on_warn, as
> dns_resolver_preparse can trigger a WARN_ONCE() in the bowels of
> printk(), and we recurse on a lock that's already held.
> 
> The underlying issue is that dns_resolver_preparse() may try to dump an
> arbitrarily large chunk of user-provided data, even from an unprivileged
> user, while printk() has some internal limit on string precision.
> 
> On bare metal (without panic_on_warn), this means I get the following in
> my dmesg:
> 
> $ ./repro
> [   56.870339] Option '   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>  
> [   56.870350] [ cut here ]
> [   56.870355] precision 1044478 too large
> [   56.870362] WARNING: CPU: 2 PID: 2450 at lib/vsprintf.c:2179 
> vsnprintf+0xdf0/0x1268
> [   56.870366] Modules linked in:
> [   56.870376] CPU: 2 PID: 2450 Comm: repro Not tainted 
> 4.16.0-rc3-2-g544c20187688-dirty #4
> [   56.870382] Hardware name: ARM Juno development board (r1) (DT)
> [   56.870386] pstate: 8085 (Nzcv daIf -PAN -UAO)
> [   56.870390] pc : vsnprintf+0xdf0/0x1268
> [   56.870394] lr : vsnprintf+0xdf0/0x1268
> [   56.870398] sp : 80092b41f6f0
> [   56.870401] x29: 80092b41f6f0 x28: 2b093f36
> [   56.870411] x27: 03e0 x26: 0002
> [   56.870421] x25: 000feffe x24: 100125683eee
> [   56.870431] x23: 2a433200 x22: 2bc5f3c0
> [   56.870440] x21: dfff2000 x20: 2bc5efea
> [   56.870450] x19: 2a4329ce x18: c51e5860
> [   56.870459] x17: 00411018 x16: 28957d28
> [   56.870469] x15: f200 x14: 2aa0a6c0
> [   56.870479] x13:  x12: 2aa0a000
> [   56.870488] x11: 100126eda462 x10: 100126eda462
> [   56.870498] x9 : dfff2000 x8 : 
> [   56.870507] x7 : 8009376d2311 x6 : 8009376d2312
> [   56.870517] x5 : 100126eda463 x4 : 100126eda463
> [   56.870526] x3 :  x2 : 0001
> [   56.870536] x1 : fdb9418241605c00 x0 : 
> [   56.870545] Call trace:
> [   56.870549]  vsnprintf+0xdf0/0x1268
> [   56.870553]  vscnprintf+0x48/0x88
> [   56.870556]  vprintk_emit+0xac/0x5f0
> [   56.870560]  vprintk_default+0x44/0x50
> [   56.870564]  vprintk_func+0x3dc/0x630
> [   56.870568]  printk+0xbc/0xec
> [   56.870572]  dns_resolver_preparse+0x5bc/0x6e8
> [   56.870576]  key_create_or_update+0x298/0x828
> [   56.870580]  SyS_add_key+0x110/0x3c8
> [   56.870584]  el0_svc_naked+0x30/0x34
> [   56.870589] ---[ end trace 2b46801cfa43d927 ]---
> 
> Any ideas on how to avoid this?
> 
> Thanks,
> Mark.
> 
> >8
> #include 
> #include 
> 
> #define BUF_SIZE 0xff000
> 
> static char buf[BUF_SIZE] = {
>   [0] = '#',
>   [1 ... BUF_SIZE - 2] = 'a'
> };
> 
> int main()
> {
>   syscall(__NR_add_key, "dns_resolver", "a", buf, BUF_SIZE, -1);
>   return 0;
> }
> 

Thanks for the bug report.  At the very least I think dns_resolver_preparse()
should limit the option string lengths.  After all, the only accepted option
currently is "dnserror".  I'll send a patch.

Eric

Re: [PATCH V4 1/2] ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE

[Eric Biggers]

Hi Jason,

On Fri, Feb 09, 2018 at 05:45:49PM +0800, Jason Wang wrote:
> To avoid slab to warn about exceeded size, fail early if queue
> occupies more than KMALLOC_MAX_SIZE.
> 
> Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com
> Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
> Signed-off-by: Jason Wang 
> ---
>  include/linux/ptr_ring.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> index 1883d61..6051a5f 100644
> --- a/include/linux/ptr_ring.h
> +++ b/include/linux/ptr_ring.h
> @@ -466,6 +466,8 @@ static inline int ptr_ring_consume_batched_bh(struct 
> ptr_ring *r,
>  
>  static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t 
> gfp)
>  {
> + if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
> + return NULL;

Are you sure that size can't be over 0x4000?  The proper way to write this
(safe from integer overflow) would be:

if (size > KMALLOC_MAX_SIZE / sizeof(void *))
return NULL;

- Eric

Re: INFO: task hung in bpf_exit_net

[Eric Biggers]

On Fri, Dec 22, 2017 at 05:04:37PM -0200, Marcelo Ricardo Leitner wrote:
> On Fri, Dec 22, 2017 at 04:28:07PM -0200, Marcelo Ricardo Leitner wrote:
> > On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
> > ...
> > > > Same with this one, perhaps related to / fixed by:
> > > > http://patchwork.ozlabs.org/patch/850957/
> > > >
> > > 
> > > 
> > > 
> > > Looking at the log, this one seems to be an infinite loop in SCTP code
> > > with console output in it. Kernel is busy printing gazilion of:
> > > 
> > > [  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > > low, using default minimum of 512
> > > ** 110 printk messages dropped **
> > > [  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > > low, using default minimum of 512
> > > ** 103 printk messages dropped **
> > > ...
> > > [  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > > low, using default minimum of 512
> > > [  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > > low, using default minimum of 512
> > > [  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > > low, using default minimum of 512
> > > 
> > > Looks like a different issue.
> > > 
> > 
> > Oh. I guess this is caused by the interface having a MTU smaller than
> > SCTP_DEFAULT_MINSEGMENT (512), as the icmp frag needed handler
> > (sctp_icmp_frag_needed) will trigger an instant retransmission.
> > But as the MTU is smaller, SCTP won't update it, but will issue the
> > retransmission anyway.
> > 
> > I will test this soon. Should be fairly easy to trigger it.
> 
> Reproduced it.
> 
> netns A veth0(1500) - veth1(1500) B veth2(508) - veth3(508) C
> 
> When A sends a sctp packet bigger than 508, it triggers the issue as B
> will reply a icmp frag needed with a size that sctp won't accept but
> will retransmit anyway.
> 

syzbot hasn't encountered this hang again (although, it just happened once in
the first place).  I assume it was fixed by commit b6c5734db070, so telling
syzbot this:

#syz fix: sctp: fix the handling of ICMP Frag Needed for too small MTUs

- Eric

Re: INFO: trying to register non-static key in pfifo_fast_reset

[Eric Biggers]

On Sun, Dec 17, 2017 at 01:56:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 41d8c16909ebda40f7b4982a7f5e2ad102705ade
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> RBP: 0008 R08: 0001 R09: 0034
> R10:  R11: 0246 R12: 30657267
> R13: 74656e2f7665642f R14:  R15: 
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 3119 Comm: syzkaller228956 Not tainted 4.15.0-rc3-next-20171213+
> #66
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0xe9/0x14b lib/dump_stack.c:53
>  register_lock_class+0x164/0x5d0 kernel/locking/lockdep.c:752
>  __lock_acquire+0xb4/0x1430 kernel/locking/lockdep.c:3314
>  lock_acquire+0xbf/0x220 kernel/locking/lockdep.c:3914
>  __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
>  _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
>  spin_lock_bh include/linux/spinlock.h:315 [inline]
>  ptr_ring_consume_bh include/linux/ptr_ring.h:349 [inline]
>  skb_array_consume_bh include/linux/skb_array.h:136 [inline]
>  pfifo_fast_reset+0x9a/0x1b0 net/sched/sch_generic.c:662
>  qdisc_destroy+0x94/0x210 net/sched/sch_generic.c:896
>  qdisc_create_dflt+0xa6/0xb0 net/sched/sch_generic.c:840
>  mq_init+0x105/0x150 net/sched/sch_mq.c:61
>  qdisc_create_dflt+0x60/0xb0 net/sched/sch_generic.c:837
>  attach_default_qdiscs net/sched/sch_generic.c:972 [inline]
>  dev_activate+0x363/0x3b0 net/sched/sch_generic.c:1011
>  __dev_open+0x119/0x180 net/core/dev.c:1389
>  __dev_change_flags+0x218/0x270 net/core/dev.c:6836
>  dev_change_flags+0x30/0x70 net/core/dev.c:6905
>  dev_ifsioc+0x3c2/0x520 net/core/dev_ioctl.c:257
>  dev_ioctl+0x15d/0x7a0 net/core/dev_ioctl.c:566
>  sock_do_ioctl+0x59/0x60 net/socket.c:971
>  sock_ioctl+0x211/0x320 net/socket.c:1061
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0xb9
> RSP: 002b:7ffcad5a5418
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title

No longer occurring, seems to have been fixed by commit 1df94c3c5dadb:

#syz fix: net_sched: properly check for empty skb array on error path

- Eric

Re: WARNING in reuseport_add_sock

[Eric Biggers]

On Fri, Jan 12, 2018 at 03:58:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 30a7acd573899fd8b8ac39236eff6468b195ac7d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c0ea2226f77a42936...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> [ cut here ]
> socket already in reuseport group
> WARNING: CPU: 0 PID: 3496 at net/core/sock_reuseport.c:119
> reuseport_add_sock+0x742/0x9b0 net/core/sock_reuseport.c:117
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 0 PID: 3496 Comm: syzkaller869503 Not tainted 4.15.0-rc6+ #245
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __warn+0x1dc/0x200 kernel/panic.c:547
>  report_bug+0x211/0x2d0 lib/bug.c:184
>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:reuseport_add_sock+0x742/0x9b0 net/core/sock_reuseport.c:117
> RSP: 0018:8801bf5f7968 EFLAGS: 00010286
> RAX: dc08 RBX: 8801bf4905c0 RCX: 8159d9de
> RDX:  RSI: 110037ebeee8 RDI: 0293
> RBP: 8801bf5f7b00 R08: 110037ebeeaa R09: 
> R10: 8801bf5f7820 R11:  R12: 110037ebef37
> R13: 8801bf47b930 R14: 8801bf5f7ad8 R15: 110037ebef3b
>  inet_reuseport_add_sock net/ipv4/inet_hashtables.c:456 [inline]
>  __inet_hash+0x767/0xb90 net/ipv4/inet_hashtables.c:477
>  inet_hash+0x61/0x90 net/ipv4/inet_hashtables.c:501
>  inet_csk_listen_start+0x38f/0x460 net/ipv4/inet_connection_sock.c:885
>  inet_listen+0x19a/0x440 net/ipv4/af_inet.c:228
>  SYSC_listen net/socket.c:1483 [inline]
>  SyS_listen+0x1aa/0x350 net/socket.c:1469
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x445639
> RSP: 002b:7f2966197db8 EFLAGS: 0246 ORIG_RAX: 0032
> RAX: ffda RBX: 006dac24 RCX: 00445639
> RDX: 00445639 RSI:  RDI: 0006
> RBP: 006dac20 R08:  R09: 
> R10:  R11: 0246 R12: 
> R13: 7ffc328a273f R14: 7f29661989c0 R15: 0008
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 

Still happens.  Here's a simplified reproducer:

#include 
#include 
#include 

int main()
{
struct sock_filter filt = { .code = 6 };
struct sock_fprog prog = { .len = 1, .filter =  };
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_port = htobe16(2),
};

for (;;) {
int fd = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(fd, IPPROTO_TCP, IP_TRANSPARENT, &(int){ 1 }, 4);
setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &(int){ 1 }, 4);
setsockopt(fd, SOL_SOCKET, SO_ATTACH_REUSEPORT_CBPF,
   , sizeof(prog));
bind(fd, (void *), sizeof(addr));
listen(fd, 0);
}
}

Re: suspicious RCU usage at net/ipv6/ip6_fib.c:LINE

[Eric Biggers]

+wei...@google.com

On Tue, Jan 02, 2018 at 03:58:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6bb8824732f69de0f233ae6b1a8158e149627b38
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+bca7109dba5d86cb0...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> 
> =
> WARNING: suspicious RCU usage
> 4.15.0-rc5+ #171 Not tainted
> -
> net/ipv6/ip6_fib.c:1702 suspicious rcu_dereference_protected() usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 4 locks held by swapper/0/0:
>  #0:  ((>ipv6.ip6_fib_timer)){+.-.}, at: []
> lockdep_copy_map include/linux/lockdep.h:178 [inline]
>  #0:  ((>ipv6.ip6_fib_timer)){+.-.}, at: []
> call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1310
>  #1:  (&(>ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<2ff9d65c>]
> spin_lock_bh include/linux/spinlock.h:315 [inline]
>  #1:  (&(>ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<2ff9d65c>]
> fib6_run_gc+0x9d/0x3c0 net/ipv6/ip6_fib.c:2007
>  #2:  (rcu_read_lock){}, at: [<91db762d>]
> __fib6_clean_all+0x0/0x3a0 net/ipv6/ip6_fib.c:1560
>  #3:  (&(>tb6_lock)->rlock){+.-.}, at: [<9e503581>] spin_lock_bh
> include/linux/spinlock.h:315 [inline]
>  #3:  (&(>tb6_lock)->rlock){+.-.}, at: [<9e503581>]
> __fib6_clean_all+0x1d0/0x3a0 net/ipv6/ip6_fib.c:1948
> 
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc5+ #171
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
>  fib6_del+0xcaa/0x11b0 net/ipv6/ip6_fib.c:1701
>  fib6_clean_node+0x3aa/0x4f0 net/ipv6/ip6_fib.c:1892
>  fib6_walk_continue+0x46c/0x8a0 net/ipv6/ip6_fib.c:1815
>  fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1863
>  fib6_clean_tree+0x1e6/0x340 net/ipv6/ip6_fib.c:1933
>  __fib6_clean_all+0x1f4/0x3a0 net/ipv6/ip6_fib.c:1949
>  fib6_clean_all net/ipv6/ip6_fib.c:1960 [inline]
>  fib6_run_gc+0x16b/0x3c0 net/ipv6/ip6_fib.c:2016
>  fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2033
>  call_timer_fn+0x228/0x820 kernel/time/timer.c:1320
>  expire_timers kernel/time/timer.c:1357 [inline]
>  __run_timers+0x7ee/0xb70 kernel/time/timer.c:1660
>  run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>  invoke_softirq kernel/softirq.c:365 [inline]
>  irq_exit+0x1cc/0x200 kernel/softirq.c:405
>  exiting_irq arch/x86/include/asm/apic.h:540 [inline]
>  smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:904
>  
> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
> RSP: 0018:86407c38 EFLAGS: 0282 ORIG_RAX: ff11
> RAX: dc00 RBX: 10c80f8a RCX: 
> RDX: 10c99048 RSI: 0001 RDI: 864c8240
> RBP: 86407c38 R08:  R09: 
> R10:  R11:  R12: 
> R13: 86407cf0 R14: 86c329a0 R15: 
>  arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
>  default_idle+0xbf/0x460 arch/x86/kernel/process.c:355
>  arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:346
>  default_idle_call+0x36/0x90 kernel/sched/idle.c:98
>  cpuidle_idle_call kernel/sched/idle.c:156 [inline]
>  do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
>  cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:351
>  rest_init+0xed/0xf0 init/main.c:435
>  start_kernel+0x7f1/0x819 init/main.c:713
>  x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:378
>  x86_64_start_kernel+0x77/0x7a arch/x86/kernel/head64.c:359
>  secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237

Wei, was this meant to have been fixed by commit 4512c43eac7e00 ("ipv6: remove
null_entry before adding default route")?  This crash actually still occurred on
net-next as recently as 43df215d99e604 (Jan 25) which included your fix.  I will
go ahead and mark this bug fixed, but syzbot will send a new report if it hits
it again.

#syz fix: ipv6: remove null_entry before adding default route

- Eric

Re: suspicious RCU usage at net/tipc/bearer.c:LINE

[Eric Biggers]

On Sun, Dec 31, 2017 at 10:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 5aa90a84589282b87666f92b6c3c917c8080a9bf
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6345fd433db009b29...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1514679888.244:9): avc:  denied  { write } for
> pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs" ino=11143
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tclass=netlink_generic_socket permissive=1
> =
> WARNING: suspicious RCU usage
> 4.15.0-rc5+ #152 Not tainted
> -
> net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by syzkaller021477/3194:
>  #0:  (cb_lock){}, at: [] genl_rcv+0x19/0x40
> net/netlink/genetlink.c:634
>  #1:  (genl_mutex){+.+.}, at: [] genl_lock
> net/netlink/genetlink.c:33 [inline]
>  #1:  (genl_mutex){+.+.}, at: [] genl_rcv_msg+0x115/0x140
> net/netlink/genetlink.c:622
> 
> stack backtrace:
> CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ #152
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
>  tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
>  tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
>  __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
>  tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
>  tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
>  tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
>  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
>  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
>  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
>  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:646
>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
>  call_write_iter include/linux/fs.h:1772 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
> 

This is still happening; looks like a missing lock in tipc_nl_compat_link_set().
Note that the reproducer isn't guaranteed to work as-is because the message it
sends to the netlink socket assumes that the "TIPC" generic netlink family was
assigned ID 31, when actually it is a dynamically assigned ID.  But it will
trigger if you adjust the message's ->nlmsg_type accordingly.

- Eric

Re: KASAN: use-after-free Read in tipc_group_size

[Eric Biggers]

On Mon, Jan 08, 2018 at 08:11:35PM +, Jon Maloy wrote:
> 
> 
> > -Original Message-
> > From: Cong Wang [mailto:xiyou.wangc...@gmail.com]
> > Sent: Monday, January 08, 2018 13:44
> > To: syzbot 
> > Cc: David Miller ; Jon Maloy
> > ; LKML ; Linux
> > Kernel Network Developers ; syzkaller-
> > b...@googlegroups.com; tipc-discuss...@lists.sourceforge.net; Ying Xue
> > 
> > Subject: Re: KASAN: use-after-free Read in tipc_group_size
> > 
> > On Mon, Jan 8, 2018 at 6:58 AM, syzbot
> >  wrote:
> > > Hello,
> > >
> > > syzkaller hit the following crash on
> > > b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/maste
> > > r
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > > C reproducer is attached
> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ for
> > > information about syzkaller reproducers
> > >
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+aae58876fb5a1fad0...@syzkaller.appspotmail.com
> > > It will help syzbot understand when the bug is fixed. See footer for
> > > details.
> > > If you forward the report, please keep this part and the footer.
> > >
> > >
> > ==
> > 
> > > BUG: KASAN: use-after-free in tipc_group_size+0x40/0x50
> > > net/tipc/group.c:158 Read of size 2 at addr 8801c08ba280 by task
> > > syzkaller447710/3513
> > >
> > > CPU: 0 PID: 3513 Comm: syzkaller447710 Not tainted 4.15.0-rc7+ #252
> > > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > > BIOS Google 01/01/2011 Call Trace:
> > >  __dump_stack lib/dump_stack.c:17 [inline]
> > >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> > >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> > > kasan_report_error mm/kasan/report.c:351 [inline]
> > >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> > >  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
> > >  tipc_group_size+0x40/0x50 net/tipc/group.c:158
> > >  tipc_poll+0x374/0x4f0 net/tipc/socket.c:739
> > 
> > Seems we have to lock the sock for tipc_group_size() in tipc_poll().
> 
> Not quite. I think it is that we initialize 'grp' on the stack before we call 
> sock_poll_wait() and access it after it returns.
> This is anyway fixed in patch #9 of the series I just sent to net-next, where 
> the poll() handling for group members is redesigned.
> 
> ///jon
> 

Last occurred on Jan 16.  Seems to have been fixed by commit 60c2530696320:

#syz fix: tipc: fix race between poll() and setsockopt()

- Eric

Re: general protection fault in __netlink_ns_capable

[Eric Biggers]

On Thu, Jan 04, 2018 at 10:14:38AM -0800, Andrei Vagin wrote:
> On Thu, Jan 04, 2018 at 01:01:17PM +0100, Dmitry Vyukov wrote:
> > On Wed, Jan 3, 2018 at 8:37 AM, Andrei Vagin  wrote:
> > >> > Hello,
> > >> >
> > >> > syzkaller hit the following crash on
> > >> > 75aa5540627fdb3d8f86229776ea87f995275351
> > >> > git://git.cmpxchg.org/linux-mmots.git/master
> > >> > compiler: gcc (GCC) 7.1.1 20170620
> > >> > .config is attached
> > >> > Raw console output is attached.
> > >> > C reproducer is attached
> > >> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > >> > for information about syzkaller reproducers
> > >> >
> > >> >
> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> > >> > commit:
> > >> > Reported-by: syzbot+e432865c29eb4c48c...@syzkaller.appspotmail.com
> > >> > It will help syzbot understand when the bug is fixed. See footer for
> > >> > details.
> > >> > If you forward the report, please keep this part and the footer.
> > >> >
> > >> > netlink: 3 bytes leftover after parsing attributes in process
> > >> > `syzkaller140561'.
> > >> > netlink: 3 bytes leftover after parsing attributes in process
> > >> > `syzkaller140561'.
> > >> > netlink: 3 bytes leftover after parsing attributes in process
> > >> > `syzkaller140561'.
> > >> > kasan: CONFIG_KASAN_INLINE enabled
> > >> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > >> > general protection fault:  [#1] SMP KASAN
> > >> > Dumping ftrace buffer:
> > >> >(ftrace buffer empty)
> > >> > Modules linked in:
> > >> > CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
> > >> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > >> > Google 01/01/2011
> > >> > RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868
> > >>
> > >> NETLINK_CB(skb).sk is NULL here. It looks like we have to use
> > >> sk_ns_capable instead of netlink_ns_capable:
> > >>
> > >> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> > >> index c688dc564b11..408c75de52ea 100644
> > >> --- a/net/core/rtnetlink.c
> > >> +++ b/net/core/rtnetlink.c
> > >> @@ -1762,7 +1762,7 @@ static struct net *get_target_net(struct sk_buff
> > >> *skb, int netnsid)
> > >> /* For now, the caller is required to have CAP_NET_ADMIN in
> > >>  * the user namespace owning the target net ns.
> > >>  */
> > >> -   if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
> > >> +   if (!sk_ns_capable(skb->sk, net->user_ns, CAP_NET_ADMIN)) {
> > >> put_net(net);
> > >> return ERR_PTR(-EACCES);
> > >> }
> > >>
> > >
> > > get_target_net() is used twice in the code. In rtnl_getlink(), we need
> > > to use netlink_ns_capable(skb, ...), but in rtnl_dump_ifinfo, we need to
> > > use sk_ns_capable(skb->sk, ...).
> > >
> > > Pls, take a look at this patch:
> > > https://patchwork.ozlabs.org/patch/854896/
> > > Subject: rtnetlink: give a user socket to get_target_net()
> > 
> > 
> > Please include this tag into the commit:
> > 
> 
> I sent v2 with this tag. Sorry for inconvenience.
> https://patchwork.ozlabs.org/patch/855147/
> 
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+e432865c29eb4c48c...@syzkaller.appspotmail.com
> > > > It will help syzbot understand when the bug is fixed.

This crash is no longer occurring, thanks Andrei!  The Reported-by tag didn't
actually make it into the commit (f428fe4a04cc), so I'll tell syzbot instead:

#syz fix: rtnetlink: give a user socket to get_target_net()

- Eric

Re: KASAN: double-free or invalid-free in skb_free_head

[Eric Biggers]

On Sun, Dec 17, 2017 at 09:52:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> ==
> BUG: KASAN: double-free or invalid-free in skb_free_head+0x74/0xb0
> net/core/skbuff.c:550
> 
> CPU: 0 PID: 3142 Comm: sshd Not tainted 4.15.0-rc3+ #225
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_double_free+0x55/0x80 mm/kasan/report.c:333
>  kasan_slab_free+0xa3/0xc0 mm/kasan/kasan.c:514
>  __cache_free mm/slab.c:3488 [inline]
>  kfree+0xca/0x250 mm/slab.c:3803
>  skb_free_head+0x74/0xb0 net/core/skbuff.c:550
>  skb_release_data+0x58c/0x790 net/core/skbuff.c:570
>  skb_release_all+0x4a/0x60 net/core/skbuff.c:627
>  __kfree_skb net/core/skbuff.c:641 [inline]
>  consume_skb+0x153/0x490 net/core/skbuff.c:701
>  __dev_kfree_skb_any+0x85/0xa0 net/core/dev.c:2515
>  dev_consume_skb_any include/linux/netdevice.h:3276 [inline]
>  free_old_xmit_skbs.isra.28+0x15a/0x2c0 drivers/net/virtio_net.c:1167
>  start_xmit+0x1b9/0x1650 drivers/net/virtio_net.c:1314
>  __netdev_start_xmit include/linux/netdevice.h:4042 [inline]
>  netdev_start_xmit include/linux/netdevice.h:4051 [inline]
>  xmit_one net/core/dev.c:2991 [inline]
>  dev_hard_start_xmit+0x248/0xac0 net/core/dev.c:3007
>  sch_direct_xmit+0x31d/0x6d0 net/sched/sch_generic.c:187
>  __dev_xmit_skb net/core/dev.c:3189 [inline]
>  __dev_queue_xmit+0x16f4/0x2070 net/core/dev.c:3456
>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3521
>  neigh_hh_output include/net/neighbour.h:472 [inline]
>  neigh_output include/net/neighbour.h:480 [inline]
>  ip_finish_output2+0xece/0x1460 net/ipv4/ip_output.c:229
>  ip_finish_output+0x85e/0xd10 net/ipv4/ip_output.c:317
>  NF_HOOK_COND include/linux/netfilter.h:239 [inline]
>  ip_output+0x1cc/0x860 net/ipv4/ip_output.c:405
>  dst_output include/net/dst.h:460 [inline]
>  ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124
>  ip_queue_xmit+0x8c6/0x18e0 net/ipv4/ip_output.c:504
>  tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176
>  tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367
>  __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543
>  tcp_push+0x538/0x770 net/ipv4/tcp.c:730
>  tcp_sendmsg_locked+0x2663/0x3b30 net/ipv4/tcp.c:1424
>  tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1461
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:646
>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
>  call_write_iter include/linux/fs.h:1772 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x7f7a61d22370
> RSP: 002b:7ffc93b90b98 EFLAGS: 0246 ORIG_RAX: 0001
> RAX: ffda RBX: 563815b397d0 RCX: 7f7a61d22370
> RDX: 0038 RSI: 563815b2b460 RDI: 0003
> RBP: 7ffc93b90b20 R08: 0001 R09: 0101010101010101
> R10: 0008 R11: 0246 R12: 0040
> R13: 005e R14: 563815b304e0 R15: 7ffc93b90b70
> 
> Allocated by task 3142:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc_node mm/slab.c:3672 [inline]
>  __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3686
>  __kmalloc_reserve.isra.41+0x41/0xd0 net/core/skbuff.c:137
>  __alloc_skb+0x13b/0x780 net/core/skbuff.c:205
>  alloc_skb_fclone include/linux/skbuff.h:1025 [inline]
>  sk_stream_alloc_skb+0x11d/0x900 net/ipv4/tcp.c:870
>  tcp_sendmsg_locked+0x1341/0x3b30 net/ipv4/tcp.c:1299
>  tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1461
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:646
>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
>  call_write_iter include/linux/fs.h:1772 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 3142:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track 

Re: KASAN: slab-out-of-bounds Read in sctp_send_reset_streams

[Eric Biggers]

On Sat, Dec 09, 2017 at 02:40:00AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 328b4ed93b69a6f2083d52f31a240a09e5de386a
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> ==
> BUG: KASAN: slab-out-of-bounds in sctp_send_reset_streams+0xadf/0xc10
> net/sctp/stream.c:314
> Read of size 2 at addr 8801d8a6c048 by task syzkaller104411/3085
> 
> CPU: 0 PID: 3085 Comm: syzkaller104411 Not tainted 4.15.0-rc2+ #119
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
>  sctp_send_reset_streams+0xadf/0xc10 net/sctp/stream.c:314
>  sctp_setsockopt_reset_streams net/sctp/socket.c:3905 [inline]
>  sctp_setsockopt+0x70d/0x5d50 net/sctp/socket.c:4195
>  compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981
>  C_SYSC_setsockopt net/compat.c:403 [inline]
>  compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> RIP: 0023:0xf7f1bc79
> RSP: 002b:ff9893bc EFLAGS: 0282 ORIG_RAX: 016e
> RAX: ffda RBX: 0005 RCX: 0084
> RDX: 0077 RSI: 2018b000 RDI: 0008
> RBP: 001c R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> 
> Allocated by task 3085:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc mm/slab.c:3711 [inline]
>  __kmalloc_track_caller+0x15e/0x760 mm/slab.c:3726
>  memdup_user+0x2c/0x90 mm/util.c:164
>  sctp_setsockopt_reset_streams net/sctp/socket.c:3897 [inline]
>  sctp_setsockopt+0x6a6/0x5d50 net/sctp/socket.c:4195
>  compat_sock_common_setsockopt+0x104/0x140 net/core/sock.c:2981
>  C_SYSC_setsockopt net/compat.c:403 [inline]
>  compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> 
> Freed by task 16:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3491 [inline]
>  kfree+0xca/0x250 mm/slab.c:3806
>  selinux_cred_free+0x48/0x70 security/selinux/hooks.c:3814
>  security_cred_free+0x48/0x80 security/security.c:995
>  put_cred_rcu+0x106/0x400 kernel/cred.c:117
>  __rcu_reclaim kernel/rcu/rcu.h:195 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>  rcu_process_callbacks+0xd74/0x17d0 kernel/rcu/tree.c:2996
>  __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
> 
> The buggy address belongs to the object at 8801d8a6c040
>  which belongs to the cache kmalloc-32 of size 32
> The buggy address is located 8 bytes inside of
>  32-byte region [8801d8a6c040, 8801d8a6c060)
> The buggy address belongs to the page:
> page:6b05592a count:1 mapcount:0 mapping:1ca7267d
> index:0x8801d8a6cfc1
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801d8a6c000 8801d8a6cfc1 0001003f
> raw: ea000762f920 ea00076133e0 8801db0001c0 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801d8a6bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  8801d8a6bf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > 8801d8a6c000: fb fb fb fb fc fc fc fc 00 fc fc fc fc fc fc fc
>   ^
>  8801d8a6c080: fb fb fb fb fc fc fc fc 00 00 00 00 fc fc fc fc
>  8801d8a6c100: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
> ==
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 

Re: WARNING in refcount_inc (2)

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:26:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> audit: type=1400 audit(1513711436.700:7): avc:  denied  { map } for
> pid=3124 comm="syzkaller396275" path="/root/syzkaller396275826" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> [ cut here ]
> refcount_t: increment on 0; use-after-free.
> WARNING: CPU: 1 PID: 3125 at lib/refcount.c:153 refcount_inc+0x47/0x50
> lib/refcount.c:153
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3125 Comm: syzkaller396275 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0xe9/0x14b lib/dump_stack.c:53
>  panic+0x10e/0x2f8 kernel/panic.c:183
>  __warn+0x14e/0x150 kernel/panic.c:547
>  report_bug+0x11e/0x1a0 lib/bug.c:184
>  fixup_bug.part.11+0x17/0x30 arch/x86/kernel/traps.c:177
>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>  do_error_trap+0x14a/0x180 arch/x86/kernel/traps.c:295
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
> RSP: 0018:c9000186bb90 EFLAGS: 00010282
> RAX: 002b RBX: 880214e2f800 RCX: 8123dede
> RDX:  RSI: 880214d5f018 RDI: 0293
> RBP: c9000186bb98 R08:  R09: 
> R10: c9000186bb18 R11:  R12: 8162ef10
> R13: 8802156d2578 R14: 8802156d2600 R15: 0001
>  get_ipc_ns include/linux/ipc_namespace.h:129 [inline]
>  __get_ns_from_inode ipc/mqueue.c:110 [inline]
>  get_ns_from_inode ipc/mqueue.c:118 [inline]
>  mqueue_evict_inode+0x69/0x340 ipc/mqueue.c:402
>  evict+0x102/0x230 fs/inode.c:552
>  iput_final fs/inode.c:1514 [inline]
>  iput+0x32b/0x400 fs/inode.c:1541
>  dentry_unlink_inode+0x1ab/0x1e0 fs/dcache.c:375
>  __dentry_kill+0x12d/0x210 fs/dcache.c:572
>  shrink_dentry_list+0x140/0x660 fs/dcache.c:1019
>  shrink_dcache_parent+0x2f/0x90 fs/dcache.c:1453
>  do_one_tree+0x15/0x50 fs/dcache.c:1484
>  shrink_dcache_for_umount+0x37/0xb0 fs/dcache.c:1501
>  generic_shutdown_super+0x2d/0x170 fs/super.c:424
>  kill_anon_super fs/super.c:987 [inline]
>  kill_litter_super+0x36/0x50 fs/super.c:997
>  deactivate_locked_super+0x4d/0x80 fs/super.c:312
>  deactivate_super+0x61/0x90 fs/super.c:343
>  cleanup_mnt+0x49/0x90 fs/namespace.c:1173
>  __cleanup_mnt+0x16/0x20 fs/namespace.c:1180
>  task_work_run+0xa3/0xe0 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x3e6/0x1050 kernel/exit.c:869
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x18/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96

I'm not able to reproduce this anymore.  Looks like it was another report of the
bug in the patch "ipc, mqueue: lazy call kern_mount_data in new namespaces"
which was present in linux-next for a while but was replaced by "mqueue: switch
to on-demand creation of internal mount" which no longer has the bug.

This report was also on the linux-next version where KASAN had accidentally
gotten disabled in the syzbot config.

So, I'm invalidating this bug so that syzbot can report similar crashes again:

#syz invalid

Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
refcount_t WARNINGs; maybe those should be on a blacklist?

- Eric

Re: KASAN: use-after-free Read in map_lookup_elem

[Eric Biggers]

On Fri, Jan 12, 2018 at 02:58:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 4147d50978df60f34d444c647dde9e5b34a4315e
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d9b83ca6cd9450add...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1515719240.359:8): avc:  denied  { sys_admin } for
> pid=3510 comm="syzkaller886548" capability=21
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> audit: type=1400 audit(1515719240.417:9): avc:  denied  { sys_chroot } for
> pid=3511 comm="syzkaller886548" capability=18
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> ==
> BUG: KASAN: use-after-free in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: use-after-free in map_lookup_elem+0x4dc/0xbd0
> kernel/bpf/syscall.c:584
> Read of size 4 at addr 8801bf5a9858 by task syzkaller886548/3511
> 
> CPU: 0 PID: 3511 Comm: syzkaller886548 Not tainted 4.15.0-rc7-mm1+ #53
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:344 [inline]
>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>  SYSC_bpf kernel/bpf/syscall.c:1808 [inline]
>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x440ab9
> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
> RAX: ffda RBX:  RCX: 00440ab9
> RDX: 0018 RSI: 20c3c000 RDI: 0001
> RBP:  R08:  R09: 
> R10:  R11: 0203 R12: 00402290
> R13: 00402320 R14:  R15: 
> 
> Allocated by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3607
>  kmalloc include/linux/slab.h:515 [inline]
>  kzalloc include/linux/slab.h:704 [inline]
>  do_execveat_common.isra.30+0x3ea/0x22a0 fs/exec.c:1730
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> Freed by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd9/0x260 mm/slab.c:3800
>  free_bprm+0x19d/0x200 fs/exec.c:1415
>  do_execveat_common.isra.30+0x19e1/0x22a0 fs/exec.c:1813
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> The buggy address belongs to the object at 8801bf5a97c0
>  which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 152 bytes inside of
>  256-byte region [8801bf5a97c0, 8801bf5a98c0)
> The buggy address belongs to the page:
> page:ea0006fd6a40 count:1 mapcount:0 mapping:8801bf5a9040 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801bf5a9040  0001000c
> raw: ea0006fd6920 ea0006fdc520 8801dac007c0 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801bf5a9700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  8801bf5a9780: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> > 8801bf5a9800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
>  8801bf5a9880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>  8801bf5a9900: fb fb fb 

Re: KASAN: use-after-free Read in refcount_inc_not_zero

[Eric Biggers]

On Thu, Dec 14, 2017 at 10:23:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> ==
> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:183
> [inline]
> BUG: KASAN: use-after-free in atomic_read arch/x86/include/asm/atomic.h:27
> [inline]
> BUG: KASAN: use-after-free in refcount_inc_not_zero+0x16e/0x180
> lib/refcount.c:120
> Read of size 4 at addr 8801c51bb200 by task syzkaller711981/3156
> 
> CPU: 1 PID: 3156 Comm: syzkaller711981 Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
>  __read_once_size include/linux/compiler.h:183 [inline]
>  atomic_read arch/x86/include/asm/atomic.h:27 [inline]
>  refcount_inc_not_zero+0x16e/0x180 lib/refcount.c:120
>  refcount_inc+0x15/0x50 lib/refcount.c:153
>  get_ipc_ns include/linux/ipc_namespace.h:129 [inline]
>  __get_ns_from_inode ipc/mqueue.c:110 [inline]
>  get_ns_from_inode ipc/mqueue.c:118 [inline]
>  mqueue_evict_inode+0x137/0x9c0 ipc/mqueue.c:402
>  evict+0x481/0x920 fs/inode.c:552
>  iput_final fs/inode.c:1514 [inline]
>  iput+0x7b9/0xaf0 fs/inode.c:1541
>  dentry_unlink_inode+0x4b0/0x5e0 fs/dcache.c:376
>  __dentry_kill+0x3b7/0x6d0 fs/dcache.c:573
>  shrink_dentry_list+0x3c5/0xcf0 fs/dcache.c:1020
>  shrink_dcache_parent+0xba/0x230 fs/dcache.c:1454
>  do_one_tree+0x15/0x50 fs/dcache.c:1485
>  shrink_dcache_for_umount+0xbb/0x290 fs/dcache.c:1502
>  generic_shutdown_super+0xcd/0x540 fs/super.c:424
>  kill_anon_super fs/super.c:987 [inline]
>  kill_litter_super+0x72/0x90 fs/super.c:997
>  deactivate_locked_super+0x88/0xd0 fs/super.c:312
>  deactivate_super+0x141/0x1b0 fs/super.c:343
>  cleanup_mnt+0xb2/0x150 fs/namespace.c:1173
>  __cleanup_mnt+0x16/0x20 fs/namespace.c:1180
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ae0 kernel/exit.c:869
>  do_group_exit+0x149/0x400 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x440729
> RSP: 002b:7ffd090ef228 EFLAGS: 0206 ORIG_RAX: 00e7
> RAX: ffda RBX: 0030656c69662f2e RCX: 00440729
> RDX: 00440729 RSI:  RDI: 0001
> RBP: 006cb018 R08:  R09: 004002c8
> R10:  R11: 0206 R12: 00401bf0
> R13: 00401c80 R14:  R15: 
> 
> Allocated by task 3156:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
>  kmalloc include/linux/slab.h:516 [inline]
>  create_ipc_ns ipc/namespace.c:45 [inline]
>  copy_ipcs+0x1b3/0x520 ipc/namespace.c:96
>  create_new_namespaces+0x278/0x880 kernel/nsproxy.c:87
>  unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:206
>  SYSC_unshare kernel/fork.c:2421 [inline]
>  SyS_unshare+0x653/0xfa0 kernel/fork.c:2371
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 3156:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kfree+0xca/0x250 mm/slab.c:3807
>  free_ipc_ns ipc/namespace.c:139 [inline]
>  put_ipc_ns+0x112/0x150 ipc/namespace.c:164
>  free_nsproxy+0xc0/0x1f0 kernel/nsproxy.c:180
>  switch_task_namespaces+0x9d/0xc0 kernel/nsproxy.c:229
>  exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:234
>  do_exit+0x9b6/0x1ae0 kernel/exit.c:868
>  do_group_exit+0x149/0x400 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 

syzbot hasn't hit this crash since next-20171221, and it looks like it was
caused by the patch "ipc, mqueue: lazy call kern_mount_data in new namespaces"
which was dropped and replaced by "mqueue: switch to on-demand creation of
internal mount" (thanks Al!).  So, invalidating this bug so that syzbot can
report crashes here again if they occur.

#syz invalid

- Eric

Re: KASAN: stack-out-of-bounds Read in rds_sendmsg

[Eric Biggers]

On Thu, Dec 21, 2017 at 08:44:32AM -0800, Santosh Shilimkar wrote:
> +Avinash
> 
> On 12/21/2017 1:10 AM, syzbot wrote:
> > syzkaller has found reproducer for the following crash on
> 
> [..]
> 
> > 
> > audit: type=1400 audit(1513847224.110:7): avc:  denied  { map } for
> > pid=3157 comm="syzkaller455006" path="/root/syzkaller455006870"
> > dev="sda1" ino=16481
> > scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> > ==
> > BUG: KASAN: stack-out-of-bounds in rds_rdma_bytes net/rds/send.c:1013
> > [inline]
> 
> Could you please post the discussed fix if you are ready with it ?
> This new report is same as last one and cmesg length check should
> address it.
> 
> Regards,
> Santosh
> 

This crash seems to have stopped occurring.  I assume it was fixed by commit
14e138a86f63 (thanks Avinash!), so let's tell syzbot so that it can start
reporting crashes in the same place again:

#syz fix: RDS: Check cmsg_len before dereferencing CMSG_DATA

- Eric

Re: KASAN: use-after-free Read in sctp_association_free

[Eric Biggers]

On Thu, Nov 02, 2017 at 08:07:27PM +0800, Xin Long wrote:
> On Thu, Nov 2, 2017 at 1:55 AM, syzbot
> 
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 25a5d23b47994cdb451dcd2bc8ac310a1492f71b
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> >
> >
> > ==
> > BUG: KASAN: use-after-free in sctp_association_free+0x7b7/0x930
> > net/sctp/associola.c:333
> > Read of size 8 at addr 8801d21d4720 by task syzkaller504854/3007
> >
> > CPU: 0 PID: 3007 Comm: syzkaller504854 Not tainted 4.14.0-rc6+ #62
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:16 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:52
> >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >  kasan_report_error mm/kasan/report.c:351 [inline]
> >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> >  sctp_association_free+0x7b7/0x930 net/sctp/associola.c:333
> asoc  could have been freed by sctp_stop_t1_and_abort or elsewhere
> when waiting for buf without holding sk lock.
> 
> One possible fix:
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index c75acdf..e2ea12a 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2015,7 +2015,7 @@ static int sctp_sendmsg(struct sock *sk, struct
> msghdr *msg, size_t msg_len)
> goto out_unlock;
> 
>  out_free:
> -   if (new_asoc)
> +   if (new_asoc && err != -ESRCH)
> sctp_association_free(asoc);
>  out_unlock:
> release_sock(sk);
> @@ -7976,10 +7976,11 @@ static int sctp_wait_for_sndbuf(struct
> sctp_association *asoc, long *timeo_p,
> for (;;) {
> prepare_to_wait_exclusive(>wait, ,
>   TASK_INTERRUPTIBLE);
> +   if (asoc->base.dead)
> +   goto do_dead;
> if (!*timeo_p)
> goto do_nonblock;
> -   if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING 
> ||
> -   asoc->base.dead)
> +   if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)
> goto do_error;
> if (signal_pending(current))
> goto do_interrupted;
> @@ -8004,6 +8005,10 @@ static int sctp_wait_for_sndbuf(struct
> sctp_association *asoc, long *timeo_p,
> 
> return err;
> 
> +do_dead:
> +   err = -ESRCH;
> +   goto out;
> +
>  do_error:
> err = -EPIPE;
> goto out;
> 
> will check for sure before posting. thanks.
> 
> >  sctp_sendmsg+0x2311/0x31f0 net/sctp/socket.c:2011
> >  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
> >  sock_sendmsg_nosec net/socket.c:633 [inline]
> >  sock_sendmsg+0xca/0x110 net/socket.c:643
> >  SYSC_sendto+0x352/0x5a0 net/socket.c:1750
> >  SyS_sendto+0x40/0x50 net/socket.c:1718
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:329 [inline]
> >  do_fast_syscall_32+0x3f2/0xf05 arch/x86/entry/common.c:391
> >  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:124
> > RIP: 0023:0xf7fd2c79
> > RSP: 002b:f5fca1ec EFLAGS: 0292 ORIG_RAX: 0171
> > RAX: ffda RBX: 0003 RCX: 20925000
> > RDX: 0002 RSI:  RDI: 209e1000
> > RBP: 001c R08:  R09: 
> > R10:  R11:  R12: 
> > R13:  R14:  R15: 
> >

This crash has stopped occurring.  I assume it was fixed by commit ca3af4dd28cff
(thanks Xin!), so let's tell syzbot so that it can continue to report crashes in
the same place:

#syz fix: sctp: do not free asoc when it is already dead in sctp_sendmsg

- Eric

Re: KASAN: use-after-free Read in __xfrm_state_lookup

[Eric Biggers]

On Wed, Nov 01, 2017 at 10:55:01AM -0700, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 33ad61d0f799656e8987e9c80e6e15151bb857f3
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> ==
> BUG: KASAN: use-after-free in __xfrm_state_lookup+0x695/0x6b0
> net/xfrm/xfrm_state.c:833
> Read of size 4 at addr 8801d434e538 by task syzkaller647520/2991
> 
> CPU: 1 PID: 2991 Comm: syzkaller647520 Not tainted 4.14.0-rc5+ #89
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:52
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
>  __xfrm_state_lookup+0x695/0x6b0 net/xfrm/xfrm_state.c:833
>  xfrm_state_lookup+0x8a/0x160 net/xfrm/xfrm_state.c:1592
>  xfrm_input+0x8e5/0x22f0 net/xfrm/xfrm_input.c:302
>  xfrm6_rcv_spi net/ipv6/xfrm6_input.c:30 [inline]
>  xfrm6_rcv_tnl+0x168/0x1d0 net/ipv6/xfrm6_input.c:64
>  xfrm6_rcv+0x17/0x20 net/ipv6/xfrm6_input.c:71
>  xfrm6_ah_rcv+0x166/0x300 net/ipv6/xfrm6_protocol.c:101
>  ip6_input_finish+0x36f/0x1700 net/ipv6/ip6_input.c:284
>  NF_HOOK include/linux/netfilter.h:249 [inline]
>  ip6_input+0xe9/0x560 net/ipv6/ip6_input.c:327
>  dst_input include/net/dst.h:465 [inline]
>  ip6_rcv_finish+0x1a9/0x7a0 net/ipv6/ip6_input.c:71
>  NF_HOOK include/linux/netfilter.h:249 [inline]
>  ipv6_rcv+0xf28/0x1f80 net/ipv6/ip6_input.c:208
>  __netif_receive_skb_core+0x1a3e/0x34b0 net/core/dev.c:4477
>  __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4542
>  process_backlog+0x203/0x740 net/core/dev.c:5221
>  napi_poll net/core/dev.c:5619 [inline]
>  net_rx_action+0x792/0x1910 net/core/dev.c:5685
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:284
>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:957
>  
>  do_softirq.part.22+0x14d/0x190 kernel/softirq.c:328
>  do_softirq kernel/softirq.c:176 [inline]
>  __local_bh_enable_ip+0x135/0x160 kernel/softirq.c:181
>  local_bh_enable include/linux/bottom_half.h:31 [inline]
>  rcu_read_unlock_bh include/linux/rcupdate.h:727 [inline]
>  ip6_finish_output2+0xb26/0x22a0 net/ipv6/ip6_output.c:121
>  ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
>  NF_HOOK_COND include/linux/netfilter.h:238 [inline]
>  ip6_output+0x1f4/0x850 net/ipv6/ip6_output.c:163
>  dst_output include/net/dst.h:459 [inline]
>  ip6_local_out+0x95/0x160 net/ipv6/output_core.c:176
>  ip6_send_skb+0xa1/0x330 net/ipv6/ip6_output.c:1658
>  ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1678
>  rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
>  rawv6_sendmsg+0x2eb9/0x3e40 net/ipv6/raw.c:935
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x352/0x5a0 net/socket.c:1750
>  SyS_sendto+0x40/0x50 net/socket.c:1718
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
[...]
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title

Crash is no longer occurring, thanks Florian!

#syz fix: xfrm: defer daddr pointer assignment after spi parsing

Re: KASAN: slab-out-of-bounds Read in xfrm_hash_rebuild

[Eric Biggers]

On Thu, Dec 21, 2017 at 05:48:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 8f36e00065436412a02d1f50ad77375bdb506300
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> ==
> BUG: KASAN: slab-out-of-bounds in xfrm_hash_rebuild+0xdbe/0xf00
> net/xfrm/xfrm_policy.c:618
> Read of size 2 at addr 8801c8e92fe4 by task kworker/1:1/23
> 
> CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 4.15.0-rc3+ #161
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events xfrm_hash_rebuild
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
>  xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
>  process_one_work+0xbbf/0x1b10 kernel/workqueue.c:2112
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:441
> 
> Allocated by task 3152:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc mm/slab.c:3708 [inline]
>  __kmalloc+0x162/0x760 mm/slab.c:3717
>  kmalloc include/linux/slab.h:504 [inline]
>  sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1471
>  sk_alloc+0x8c/0x730 net/core/sock.c:1525
>  pfkey_create+0x2b2/0xae0 net/key/af_key.c:158
>  __sock_create+0x4d4/0x850 net/socket.c:1257
>  sock_create net/socket.c:1297 [inline]
>  SYSC_socket net/socket.c:1327 [inline]
>  SyS_socket+0xeb/0x1d0 net/socket.c:1307
>  entry_SYSCALL_64_fastpath+0x1f/0x96

#syz fix: xfrm: skip policies marked as dead while rehashing

Re: [PATCH ipsec] xfrm: skip policies marked as dead while rehashing

[Eric Biggers]

On Sun, Dec 31, 2017 at 08:50:17AM +0100, Steffen Klassert wrote:
> On Wed, Dec 27, 2017 at 11:25:45PM +0100, Florian Westphal wrote:
> > syzkaller triggered following KASAN splat:
> > 
> > BUG: KASAN: slab-out-of-bounds in xfrm_hash_rebuild+0xdbe/0xf00 
> > net/xfrm/xfrm_policy.c:618
> > read of size 2 at addr 8801c8e92fe4 by task kworker/1:1/23 [..]
> > Workqueue: events xfrm_hash_rebuild [..]
> >  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
> >  xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
> >  process_one_work+0xbbf/0x1b10 kernel/workqueue.c:2112
> >  worker_thread+0x223/0x1990 kernel/workqueue.c:2246 [..]
> > 
> > The reproducer triggers:
> > 1016 if (error) {
> > 1017 list_move_tail(>walk.all, >all);
> > 1018 goto out;
> > 1019 }
> > 
> > in xfrm_policy_walk() via pfkey (it sets tiny rcv space, dump
> > callback returns -ENOBUFS).
> > 
> > In this case, *walk is located the pfkey socket struct, so this socket
> > becomes visible in the global policy list.
> > 
> > It looks like this is intentional -- phony walker has walk.dead set to 1
> > and all other places skip such "policies".
> > 
> > Ccing original authors of the two commits that seem to expose this
> > issue (first patch missed ->dead check, second patch adds pfkey
> > sockets to policies dumper list).
> > 
> > Fixes: 880a6fab8f6ba5b ("xfrm: configure policy hash table thresholds by 
> > netlink")
> > Fixes: 12a169e7d8f4b1c ("ipsec: Put dumpers on the dump list")
> > Cc: Herbert Xu 
> > Cc: Timo Teras 
> > Cc: Christophe Gouault 
> > Reported-by: syzbot 
> > 
> > Signed-off-by: Florian Westphal 
> 
> Applied, thanks a lot!
> 

This crash seems to have stopped occurring, thanks Florian!  Let's tell syzbot
so that it can start reporting any crashes in this same place again:

#syz fix: xfrm: skip policies marked as dead while rehashing

- Eric

Re: KASAN: use-after-free Read in __bpf_prog_put

[Eric Biggers]

On Thu, Jan 11, 2018 at 11:48:28AM +0100, Daniel Borkmann wrote:
> Hi Dmitry,
> 
> On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> > On Thu, Jan 11, 2018 at 11:17 AM, syzbot
> >  wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> 4147d50978df60f34d444c647dde9e5b34a4315e
> >> git://git.cmpxchg.org/linux-mmots.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> Unfortunately, I don't have any reproducer for this bug yet.
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+d85bfb332db8f0794...@syzkaller.appspotmail.com
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.
> >>
> >> netlink: 3 bytes leftover after parsing attributes in process
> >> `syz-executor5'.
> >> ==
> >> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
> >> kernel/bpf/syscall.c:944
> >> netlink: 'syz-executor5': attribute type 5 has an invalid length.
> >> Read of size 8 at addr 8801d3619658 by task syz-executor0/12398
> >>
> >> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  __dump_stack lib/dump_stack.c:17 [inline]
> >>  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >>  print_address_description+0x73/0x250 mm/kasan/report.c:256
> >>  kasan_report_error mm/kasan/report.c:354 [inline]
> >>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
> >>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> >>  __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
> >>  bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
> >>  prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
> >>  fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
> >>  map_delete_elem kernel/bpf/syscall.c:737 [inline]
> >>  SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
> >>  SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
> >>  entry_SYSCALL_64_fastpath+0x29/0xa0
> >> RIP: 0033:0x452ac9
> >> RSP: 002b:7fb70df60c58 EFLAGS: 0212 ORIG_RAX: 0141
> >> RAX: ffda RBX: 0071bea0 RCX: 00452ac9
> >> RDX: 0010 RSI: 20f02ff0 RDI: 0003
> >> RBP: 03aa R08:  R09: 
> >> R10:  R11: 0212 R12: 006f3890
> >> R13:  R14: 7fb70df616d4 R15: 
> >>
> >> Allocated by task 11996:
> >>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>  set_track mm/kasan/kasan.c:459 [inline]
> >>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
> >>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> >>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
> >>  kmem_cache_zalloc include/linux/slab.h:694 [inline]
> >>  get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
> >>  path_openat+0xed/0x3530 fs/namei.c:3514
> >>  do_filp_open+0x25b/0x3b0 fs/namei.c:3572
> >>  do_sys_open+0x502/0x6d0 fs/open.c:1059
> >>  SYSC_open fs/open.c:1077 [inline]
> >>  SyS_open+0x2d/0x40 fs/open.c:1072
> >>  entry_SYSCALL_64_fastpath+0x29/0xa0
> >>
> >> Freed by task 11994:
> >>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >>  set_track mm/kasan/kasan.c:459 [inline]
> >>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
> >>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
> >>  __cache_free mm/slab.c:3485 [inline]
> >>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
> >>  file_free_rcu+0x5c/0x70 fs/file_table.c:49
> >>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
> >>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
> >>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
> >>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
> >>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
> >>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> >>
> >> The buggy address belongs to the object at 8801d36195c0
> >>  which belongs to the cache filp of size 456
> >> The buggy address is located 152 bytes inside of
> >>  456-byte region [8801d36195c0, 8801d3619788)
> >> The buggy address belongs to the page:
> >> page:ea00074d8640 count:1 mapcount:0 mapping:8801d36190c0 index:0x0
> >> flags: 0x2fffc000100(slab)
> >> raw: 02fffc000100 8801d36190c0  00010006
> >> raw: ea00074c49a0 ea000747a160 8801dae30180 
> >> page dumped because: kasan: bad access detected
> >>
> >> Memory state around the buggy address:
> >>  8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >>  8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> >>>
> >>> 8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>
> >>  

Re: BUG: unable to handle kernel paging request in check_memory_region

[Eric Biggers]

On Sun, Jan 14, 2018 at 01:22:13AM +0100, Daniel Borkmann wrote:
> On 01/13/2018 08:29 AM, Dmitry Vyukov wrote:
> > On Fri, Jan 12, 2018 at 11:58 PM, syzbot
> >  wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> c92a9a461dff6140c539c61e457aa97df29517d6
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> C reproducer is attached
> >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> >> for information about syzkaller reproducers
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+32b24f3e7c9000c48...@syzkaller.appspotmail.com
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.
> > 
> > 
> > Daniel, is it the same bug that was fixed by "bpf, array: fix overflow
> > in max_entries and undefined behavior in index_mask"?
> 
> And also here, fixed by:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1
> 

Thanks Daniel, this crash is no longer occurring and I verified that commit
bbeb6e4323da fixed it, so let's allow syzbot to close this report too:

#syz fix: bpf, array: fix overflow in max_entries and undefined behavior in 
index_mask

- Eric

Re: general protection fault in fib6_add (2)

[Eric Biggers]

On Wed, Jan 03, 2018 at 10:53:02AM -0800, 'Wei Wang' via syzkaller-bugs wrote:
> On Wed, Jan 3, 2018 at 8:16 AM, David Ahern  wrote:
> > [ +wei...@google.com ]
> >
> > On 1/2/18 3:58 PM, syzbot wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> C reproducer is attached
> >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> >> for information about syzkaller reproducers
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+0693adff3f83403dc...@syzkaller.appspotmail.com
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.

This crash seemed to stop occurring around Jan 8.  Wei, next time can you please
use the suggested Reported-by line so that syzbot knows which commit is meant to
fix the bug?  I assume it was this one:

#syz fix: ipv6: fix general protection fault in fib6_add()

Thanks!

- Eric

> >>
> >> audit: type=1400 audit(1514594846.496:7): avc:  denied  { map } for
> >> pid=3201 comm="syzkaller001778" path="/root/syzkaller001778299"
> >> dev="sda1" ino=16481
> >> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> >> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> >> IPv6: Can't replace route, no match found
> >> kasan: CONFIG_KASAN_INLINE enabled
> >> kasan: GPF could be caused by NULL-ptr deref or user memory access
> >> general protection fault:  [#1] SMP KASAN
> >> Dumping ftrace buffer:
> >>(ftrace buffer empty)
> >> Modules linked in:
> >> CPU: 0 PID: 3201 Comm: syzkaller001778 Not tainted 4.15.0-rc5+ #151
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> RIP: 0010:fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244
> 
> pn could be NULL if fib6_add_1() failed. Will submit a fix for this.
> 
> >> RSP: 0018:8801c7626a70 EFLAGS: 00010202
> >> RAX: dc00 RBX: 0020 RCX: 84794465
> >> RDX: 0004 RSI: 8801d38935f0 RDI: 0282
> >> RBP: 8801c7626da0 R08: 110038ec4c35 R09: 
> >> R10: 8801c7626c68 R11:  R12: fffe
> >> R13:  R14:  R15: 0009
> >> FS:  () GS:8801db20(0063)
> >> knlGS:09b70840
> >> CS:  0010 DS: 002b ES: 002b CR0: 80050033
> >> CR2: 20be1000 CR3: 0001d585a006 CR4: 001606f0
> >> DR0:  DR1:  DR2: 
> >> DR3:  DR6: fffe0ff0 DR7: 0400
> >> Call Trace:
> >>  __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1006
> >>  ip6_route_multipath_add+0xd14/0x16c0 net/ipv6/route.c:3833
> >>  inet6_rtm_newroute+0xdc/0x160 net/ipv6/route.c:3957
> >>  rtnetlink_rcv_msg+0x733/0x1020 net/core/rtnetlink.c:4411
> >>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
> >>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4423
> >>  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
> >>  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
> >>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
> >>  sock_sendmsg_nosec net/socket.c:636 [inline]
> >>  sock_sendmsg+0xca/0x110 net/socket.c:646
> >>  sock_write_iter+0x31a/0x5d0 net/socket.c:915
> >>  call_write_iter include/linux/fs.h:1772 [inline]
> >>  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
> >>  do_iter_write+0x154/0x540 fs/read_write.c:932
> >>  compat_writev+0x225/0x420 fs/read_write.c:1246
> >>  do_compat_writev+0x115/0x220 fs/read_write.c:1267
> >>  C_SYSC_writev fs/read_write.c:1278 [inline]
> >>  compat_SyS_writev+0x26/0x30 fs/read_write.c:1274
> >>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
> >>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
> >>  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:125
> >> RIP: 0023:0xf7f1fc79
> >> RSP: 002b:ffb61bfc EFLAGS: 0203 ORIG_RAX: 0092
> >> RAX: ffda RBX: 0003 RCX: 204aaff0
> >> RDX: 0001 RSI: 0167 RDI: 0010
> >> RBP: 0003 R08:  R09: 
> >> R10:  R11:  R12: 
> >> R13:  R14:  R15: 
> >> Code: f1 a9 f6 fc e8 2c f2 e2 fc 85 c0 0f 85 d5 03 00 00 49 8d 5e 20 e8
> >> db a9 f6 fc 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c
> >> 02 00 0f 85 5a 0c 00 00 4d 39 ee 4d 8b 7e 20 0f 95 c0 4c
> >> RIP: fib6_add+0x736/0x15a0 net/ipv6/ip6_fib.c:1244 RSP: 8801c7626a70
> >> ---[ end trace 

Re: suspicious RCU usage at ./include/linux/inetdevice.h:LINE

[Eric Biggers]

On Thu, Nov 02, 2017 at 03:53:38AM -0700, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> ce43f4fd6f103681c7485c2b1967179647e73555
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> 
> 
> 
> 
> =
> WARNING: suspicious RCU usage
> 4.14.0-rc5+ #140 Not tainted
> -
> ./include/linux/inetdevice.h:230 suspicious rcu_dereference_protected()
> usage!
> 
> other info that might help us debug this:
> 
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by syz-executor2/23859:
>  #0:  (rcu_read_lock){}, at: []
> inet_rtm_getroute+0xaa0/0x2d70 net/ipv4/route.c:2738
> 
> stack backtrace:
> CPU: 0 PID: 23859 Comm: syz-executor2 Not tainted 4.14.0-rc5+ #140
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:52
>  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4665
>  __in_dev_get_rtnl include/linux/inetdevice.h:230 [inline]
>  fib_dump_info+0x1136/0x13d0 net/ipv4/fib_semantics.c:1377
>  inet_rtm_getroute+0xf97/0x2d70 net/ipv4/route.c:2785
>  rtnetlink_rcv_msg+0x51c/0x1090 net/core/rtnetlink.c:4237
>  netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2409
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4261
>  netlink_unicast_kernel net/netlink/af_netlink.c:1273 [inline]
>  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1299
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1862
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  sock_write_iter+0x31a/0x5d0 net/socket.c:912
>  call_write_iter include/linux/fs.h:1770 [inline]
>  new_sync_write fs/read_write.c:468 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:481
>  vfs_write+0x189/0x510 fs/read_write.c:543
>  SYSC_write fs/read_write.c:588 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:580
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x452719
> RSP: 002b:7fd087b03be8 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: 00758020 RCX: 00452719
> RDX: 0024 RSI: 20226000 RDI: 0014
> RBP: 0082 R08:  R09: 
> R10:  R11: 0212 R12: 
> R13: 00a6f7ff R14: 7fd087b049c0 R15: 

No longer seeing this crash.  I assume it was fixed by the following commit
(thanks Florian!), so telling syzbot:

#syz fix: fib: fib_dump_info can no longer use __in_dev_get_rtnl

Re: WARNING: bad unlock balance in ipmr_mfc_seq_stop

[Eric Biggers]

On Fri, Dec 15, 2017 at 11:52:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> a638349bf6c29433b938141f99225b160551ff48
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> 
> =
> WARNING: bad unlock balance detected!
> 4.15.0-rc3+ #128 Not tainted
> -
> syzkaller971460/3195 is trying to release lock (mrt_lock) at:
> [<6898068d>] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
> but there are no more locks to release!
> 
> other info that might help us debug this:
> 1 lock held by syzkaller971460/3195:
>  #0:  (>lock){+.+.}, at: [<744a6565>] seq_read+0xd5/0x13d0
> fs/seq_file.c:165
> 
> stack backtrace:
> CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561
>  __lock_release kernel/locking/lockdep.c:3775 [inline]
>  lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023
>  __raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline]
>  _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
>  ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
>  traverse+0x3bc/0xa00 fs/seq_file.c:135
>  seq_read+0x96a/0x13d0 fs/seq_file.c:189
>  proc_reg_read+0xef/0x170 fs/proc/inode.c:217
>  do_loop_readv_writev fs/read_write.c:673 [inline]
>  do_iter_read+0x3db/0x5b0 fs/read_write.c:897
>  compat_readv+0x1bf/0x270 fs/read_write.c:1140
>  do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189
>  C_SYSC_preadv fs/read_write.c:1209 [inline]
>  compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> RIP: 0023:0xf7f73c79
> RSP: 002b:e574a15c EFLAGS: 0292 ORIG_RAX: 014d
> RAX: ffda RBX: 000f RCX: 20a3afb0
> RDX: 0001 RSI: 0067 RDI: 
> RBP:  R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> BUG: sleeping function called from invalid context at lib/usercopy.c:25
> in_atomic(): 1, irqs_disabled(): 0, pid: 3195, name: syzkaller971460
> INFO: lockdep is turned off.
> CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  ___might_sleep+0x2b2/0x470 kernel/sched/core.c:6060
>  __might_sleep+0x95/0x190 kernel/sched/core.c:6013
>  __might_fault+0xab/0x1d0 mm/memory.c:4525
>  _copy_to_user+0x2c/0xc0 lib/usercopy.c:25
>  copy_to_user include/linux/uaccess.h:155 [inline]
>  seq_read+0xcb4/0x13d0 fs/seq_file.c:279
>  proc_reg_read+0xef/0x170 fs/proc/inode.c:217
>  do_loop_readv_writev fs/read_write.c:673 [inline]
>  do_iter_read+0x3db/0x5b0 fs/read_write.c:897
>  compat_readv+0x1bf/0x270 fs/read_write.c:1140
>  do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189
>  C_SYSC_preadv fs/read_write.c:1209 [inline]
>  compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> RIP: 0023:0xf7f73c79
> RSP: 002b:e574a15c EFLAGS: 0292 ORIG_RAX: 014d
> RAX: ffda RBX: 000f RCX: 20a3afb0
> RDX: 0001 RSI: 0067 RDI: 
> RBP:  R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0
> lib/usercopy.c:26
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: 

Re: WARNING: bad unlock balance detected!

[Eric Biggers]

On Thu, Dec 14, 2017 at 11:37:00PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> 
> =
> WARNING: bad unlock balance detected!
> 4.15.0-rc3+ #217 Not tainted
> -
> syz-executor3/19522 is trying to release lock (mrt_lock) at:
> [] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
> but there are no more locks to release!
> 
> other info that might help us debug this:
> 2 locks held by syz-executor3/19522:
>  #0:  (>f_pos_lock){+.+.}, at: []
> __fdget_pos+0x131/0x1a0 fs/file.c:770
>  #1:  (>lock){+.+.}, at: [] seq_lseek+0x58/0x3c0
> fs/seq_file.c:321
> 
> stack backtrace:
> CPU: 0 PID: 19522 Comm: syz-executor3 Not tainted 4.15.0-rc3+ #217
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561
>  __lock_release kernel/locking/lockdep.c:3775 [inline]
>  lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023
>  __raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline]
>  _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
>  ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
>  traverse+0x3bc/0xa00 fs/seq_file.c:135
>  seq_lseek+0x136/0x3c0 fs/seq_file.c:331
>  proc_reg_llseek+0xf1/0x160 fs/proc/inode.c:203
>  vfs_llseek fs/read_write.c:300 [inline]
>  SYSC_lseek fs/read_write.c:313 [inline]
>  SyS_lseek+0xf1/0x170 fs/read_write.c:304
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7fda08e4bc58 EFLAGS: 0212 ORIG_RAX: 0008
> RAX: ffda RBX: 7fda08e4c700 RCX: 00452a39
> RDX: 0001 RSI: 0020 RDI: 0013
> RBP: 00a6f880 R08:  R09: 
> R10:  R11: 0212 R12: 
> R13: 00a6f7ff R14: 7fda08e4c9c0 R15: 0002
> BUG: scheduling while atomic: syz-executor3/19522/0x
> INFO: lockdep is turned off.
> Modules linked in:
> Kernel panic - not syncing: scheduling while atomic
> 
> CPU: 0 PID: 19522 Comm: syz-executor3 Not tainted 4.15.0-rc3+ #217
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  panic+0x1e4/0x41c kernel/panic.c:183
>  __schedule_bug+0x11f/0x130 kernel/sched/core.c:3177
>  schedule_debug kernel/sched/core.c:3194 [inline]
>  __schedule+0x131c/0x2060 kernel/sched/core.c:3299
>  schedule+0xf5/0x430 kernel/sched/core.c:3434
>  exit_to_usermode_loop+0x1d1/0x310 arch/x86/entry/common.c:151
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7fda08e4bc58 EFLAGS: 0212 ORIG_RAX: 0008
> RAX: 0040 RBX: 007580d8 RCX: 00452a39
> RDX: 0001 RSI: 0020 RDI: 0013
> RBP: 038a R08:  R09: 
> R10:  R11: 0212 R12: 006f3590
> R13:  R14: 7fda08e4c6d4 R15: 0002
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Duplicate of "WARNING: bad unlock balance in ipmr_mfc_seq_stop" which syzbot is
detecting under that crash signature now, so just invalidating this one: 

#syz invalid 

Re: WARNING in _copy_to_user

[Eric Biggers]

On Fri, Dec 01, 2017 at 03:30:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> df8ba95c572a187ed2aa7403e97a7a7f58c01f00
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> 
> =
> WARNING: bad unlock balance detected!
> 4.15.0-rc1+ #202 Not tainted
> -
> syz-executor4/28722 is trying to release lock (mrt_lock) at:
> [] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
> but there are no more locks to release!
> 
> other info that might help us debug this:
> 2 locks held by syz-executor4/28722:
>  #0:  (sb_writers#6){.+.+}, at: [<3332d098>] file_start_write
> include/linux/fs.h:2715 [inline]
>  #0:  (sb_writers#6){.+.+}, at: [<3332d098>] do_sendfile+0xaec/0xe90
> fs/read_write.c:1412
>  #1:  (>lock){+.+.}, at: [<1572c807>] seq_read+0xd5/0x13d0
> fs/seq_file.c:165
> 
> stack backtrace:
> CPU: 0 PID: 28722 Comm: syz-executor4 Not tainted 4.15.0-rc1+ #202
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561
>  __lock_release kernel/locking/lockdep.c:3775 [inline]
>  lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023
>  __raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline]
>  _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
>  ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
>  seq_read+0xc42/0x13d0 fs/seq_file.c:277
>  proc_reg_read+0xef/0x170 fs/proc/inode.c:217
>  do_loop_readv_writev fs/read_write.c:673 [inline]
>  do_iter_read+0x3db/0x5b0 fs/read_write.c:897
>  vfs_readv+0x121/0x1c0 fs/read_write.c:959
>  kernel_readv fs/splice.c:361 [inline]
>  default_file_splice_read+0x508/0xae0 fs/splice.c:416
>  do_splice_to+0x110/0x170 fs/splice.c:880
>  splice_direct_to_actor+0x242/0x820 fs/splice.c:952
>  do_splice_direct+0x2a7/0x3d0 fs/splice.c:1061
>  do_sendfile+0x5d5/0xe90 fs/read_write.c:1413
>  SYSC_sendfile64 fs/read_write.c:1468 [inline]
>  SyS_sendfile64+0xbd/0x160 fs/read_write.c:1460
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x4529d9
> RSP: 002b:7f225b206c58 EFLAGS: 0212 ORIG_RAX: 0028
> RAX: ffda RBX: 00758020 RCX: 004529d9
> RDX: 20360ff8 RSI: 0014 RDI: 0014
> RBP: 0561 R08:  R09: 
> R10: 0008 R11: 0212 R12: 006f51b8
> R13:  R14: 7f225b2076d4 R15: 
> WARNING: CPU: 0 PID: 28722 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0
> lib/usercopy.c:26
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid

Duplicate of "WARNING: bad unlock balance in ipmr_mfc_seq_stop" which syzbot is
detecting under that crash signature now, so just invalidating this one:

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free

[Eric Biggers]

On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote:
> On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
>  wrote:
> > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
> >
> > from the log:
> > [   89.451366] FAULT_INJECTION: forcing a failure.^M
> > [   89.451366] name failslab, interval 1, probability 0, space 0,
> > times 0^M
> > [   89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> > +4.15.0-rc3-next-20171214+ #67^M
> > [   89.451377] Hardware name: Google Google Compute Engine/Google
> > Compute Engine, BIOS
> > +Google 01/01/2011^M
> > [   89.451380] Call Trace:^M
> > [   89.451395]  dump_stack+0xe9/0x14b^M
> > [   89.451408]  should_fail+0x1e5/0x220^M
> > [   89.451419]  should_failslab+0x73/0x90^M
> > [   89.451428]  __kmalloc+0x63/0x730^M
> > [   89.451439]  ? rcu_read_lock_sched_held+0x74/0x80^M
> > [   89.451446]  ? __kmalloc+0x4ac/0x730^M
> > [   89.451452]  ? sctp_stream_alloc_in+0x2f/0x100^M
> > [   89.451464]  sctp_stream_alloc_in+0x2f/0x100^M
> > [   89.451473]  sctp_stream_init+0xfa/0x140^M
> > [   89.451485]  sctp_process_init+0x676/0xc50^M
> >
> > this is what caused the panic later, because in the error path we free
> > out but don't zero outcnt. This patch should fix it. Can you please
> > try it? Thanks
> >
> > 8<---
> >
> > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > index 06b644dd858c..50ab09029f00 100644
> > --- a/net/sctp/stream.c
> > +++ b/net/sctp/stream.c
> > @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 
> > outcnt, __u16 incnt,
> > sched->free(stream);
> > kfree(stream->out);
> > stream->out = NULL;
> > +   stream->outcnt = 0;
> >  out:
> > return ret;
> >  }
> 
> In case it can't be verified due to no reproducer yet, I modified some
> code in sctp_stream_init() to confirm Marcelo's deduction:
> -   i = sctp_stream_alloc_in(stream, incnt, gfp);
> +   i = 1;
> if (i) {
> ret = -ENOMEM;
> goto free;
> 
> And got the same call trace as the mail:
> 
> [  301.488065] BUG: unable to handle kernel NULL pointer dereference
> at 0008
> [  301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
> [  301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
> [  301.489372] Oops:  [#1] SMP
> [...]
> [  301.497647] Call Trace:
> [  301.497812]  
> [  301.497955]  sctp_association_free+0xb8/0x210 [sctp]
> [  301.498306]  sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
> [  301.498654]  sctp_do_sm+0x9a/0x2d0 [sctp]
> [  301.498921]  ? sctp_has_association+0x130/0x130 [sctp]
> [  301.499301]  ? kernel_text_address+0xba/0xe0
> [  301.499615]  ? check_usage_backwards+0x88/0x150
> [  301.499911]  ? __lock_acquire+0x280/0x1080
> [  301.500200]  ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
> [  301.500593]  sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
> [  301.500923]  sctp_rcv+0x9f5/0xbe0 [sctp]
> 
> And Marcelo's patch could fix it.
> 
> Since the "free:" part only works for if (i), maybe the patch can also do:
> if (i) {
> sched->free(stream);
> kfree(stream->out);
> stream->out = NULL;
> stream->outcnt = 0;
> 
> ret = -ENOMEM;
> goto out;
> }
> 
> and remove the "free:" path.

This crash seems to have stopped occurring now.  I presume it was fixed by the
following commit, so let's tell syzbot to close the bug:

#syz fix: sctp: fix error path in sctp_stream_init

Re: general protection fault in sctp_stream_free

[Eric Biggers]

On Sun, Nov 05, 2017 at 01:35:02AM -0700, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 2a171788ba7bb61995e98e8163204fc7880f63b2
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> 
> 
> 
> R13: 7ff7d3281b58 R14: 004b7560 R15: 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 17823 Comm: syz-executor4 Not tainted 4.14.0-rc7+ #109
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> task: 8801c6002380 task.stack: 8801c5fe
> RIP: 0010:sctp_stream_free+0xc3/0x1b0 net/sctp/stream.c:209
> RSP: 0018:8801c5fe6fa0 EFLAGS: 00010202
> RAX:  RBX: 8801c33fd0b0 RCX: c90003989000
> RDX: 0001 RSI: 84837f78 RDI: 0008
> RBP: 8801c5fe6fe0 R08:  R09: 110038bfcd69
> R10: 9cb59878 R11: f5f9e5c7 R12: 
> R13:  R14: dc00 R15: ed003867fa16
> FS:  7ff7d3282700() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20b50ffc CR3: 0001c4a5c000 CR4: 001406e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  sctp_association_free+0x301/0x930 net/sctp/associola.c:367
>  sctp_sf_do_unexpected_init.isra.28+0x67e/0x13b0
> net/sctp/sm_statefuns.c:1589
>  sctp_sf_do_5_2_1_siminit+0x35/0x40 net/sctp/sm_statefuns.c:1645
>  sctp_do_sm+0x18a/0x6a30 net/sctp/sm_sideeffect.c:1190
>  sctp_assoc_bh_rcv+0x283/0x4b0 net/sctp/associola.c:1065
>  sctp_inq_push+0x23b/0x300 net/sctp/inqueue.c:95
>  sctp_backlog_rcv+0x177/0xaa0 net/sctp/input.c:350
>  sk_backlog_rcv include/net/sock.h:912 [inline]
>  __release_sock+0x124/0x360 net/core/sock.c:2266
>  release_sock+0xa4/0x2a0 net/core/sock.c:2778
>  sctp_sendmsg+0x18d1/0x32b0 net/sctp/socket.c:2051
>  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x352/0x5a0 net/socket.c:1750
>  SyS_sendto+0x40/0x50 net/socket.c:1718
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x452869
> RSP: 002b:7ff7d3281be8 EFLAGS: 0212 ORIG_RAX: 002c
> RAX: ffda RBX: 007580d8 RCX: 00452869
> RDX: 0001 RSI: 206a6000 RDI: 0013
> RBP: 7ff7d3281a20 R08: 2064b000 R09: 001c
> R10: 2040 R11: 0212 R12: 004b7550
> R13: 7ff7d3281b58 R14: 004b7560 R15: 
> Code: 48 c1 e8 03 4c 01 f0 48 89 45 d0 e8 d8 b4 ea fc 41 80 3f 00 0f 85 f1
> 00 00 00 48 8b 03 4c 01 e8 48 8d 78 08 48 89 fa 48 c1 ea 03 <42> 80 3c 32 00
> 0f 85 c3 00 00 00 48 8b 78 08 41 83 c4 01 e8 85
> RIP: sctp_stream_free+0xc3/0x1b0 net/sctp/stream.c:209 RSP: 8801c5fe6fa0
> ---[ end trace cf03319dc427fb51 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title

This crash seems to have stopped occurring now.  I presume it was fixed by:

#syz fix: sctp: fix error path in sctp_stream_init

Re: WARNING in inet_sock_destruct

[Eric Biggers]

On Sun, Nov 05, 2017 at 01:05:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 7f9ad2ace17a3521a80831208d431170ef71591f
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> 
> 
> 
> refcount_t: underflow; use-after-free.
> [ cut here ]
> WARNING: CPU: 1 PID: 20526 at net/ipv4/af_inet.c:154
> inet_sock_destruct+0x729/0x950 net/ipv4/af_inet.c:154
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 20526 Comm: syz-executor3 Not tainted 4.14.0-rc4+ #85
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:52
>  panic+0x1e4/0x417 kernel/panic.c:181
>  __warn+0x1c4/0x1d9 kernel/panic.c:542
>  report_bug+0x211/0x2d0 lib/bug.c:183
>  fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
>  do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
>  do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
>  do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
>  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
> RIP: 0010:inet_sock_destruct+0x729/0x950 net/ipv4/af_inet.c:154
> RSP: 0018:8801a3d07220 EFLAGS: 00010212
> RAX: 0001 RBX: 8801c5935800 RCX: c90002ef4000
> RDX: 093f RSI: 8417f5c9 RDI: 8801c5935a60
> RBP: 8801a3d07348 R08:  R09: 1100347a0e95
> R10: 8801d7a1c340 R11: b877b192 R12: 1100347a0e54
> R13:  R14: 847daa20 R15: 8801c5935950
>  sctp_destruct_sock+0x43/0x50 net/sctp/socket.c:4508
>  __sk_destruct+0xfd/0x910 net/core/sock.c:1560
>  sk_destruct+0x47/0x80 net/core/sock.c:1595
>  __sk_free+0x57/0x230 net/core/sock.c:1603
>  sk_free+0x2a/0x40 net/core/sock.c:1614
>  sock_put include/net/sock.h:1652 [inline]
>  sctp_close+0x487/0x980 net/sctp/socket.c:1560
>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:426
>  sock_release+0x8d/0x1e0 net/socket.c:597
>  sock_close+0x16/0x20 net/socket.c:1126
>  __fput+0x333/0x7f0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:112
>  get_signal+0x1343/0x16d0 kernel/signal.c:2164
>  do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:808
>  exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
>  prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
>  syscall_return_slowpath+0x42f/0x510 arch/x86/entry/common.c:266
>  entry_SYSCALL_64_fastpath+0xbc/0xbe
> RIP: 0033:0x452719
> RSP: 002b:7fcb6e910be8 EFLAGS: 0212 ORIG_RAX: 002b
> RAX: fff2 RBX: 007580d8 RCX: 00452719
> RDX: 20b51ffc RSI: 20b52000 RDI: 0013
> RBP:  R08:  R09: 
> R10:  R11: 0212 R12: 006ee0a0
> R13:  R14: 7fcb6e9116d4 R15: 000a
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

This hasn't occurred in a long time (last crash was Oct 21) so it presumably was
fixed around then -- I'm thinking maybe by 1cc276cec9ec ("sctp: add the missing
sock_owned_by_user check in sctp_icmp_redirect").  I'll just invalidate the bug:

#syz invalid

Re: BUG: spinlock bad magic (2)

[Eric Biggers]

On Mon, Dec 18, 2017 at 06:01:30PM +0100, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> On Mon, Dec 18, 2017 at 5:46 PM, Santosh Shilimkar
>  wrote:
> > On 12/18/2017 4:36 AM, syzbot wrote:
> >>
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> 6084b576dca2e898f5c101baef151f7bfdbb606d
> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >>
> >> Unfortunately, I don't have any reproducer for this bug yet.
> >>
> > [...]
> >
> >> BUG: unable to handle kernel NULL pointer dereference at 0028
> >> IP: rds_send_xmit+0x80/0x930 net/rds/send.c:186
> >
> >
> > This one seems to be same bug as reported as below.
> >
> > BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit
> 
> Hi Santosh,
> 
> The proper syntax to tell syzbot about dups is this (from email footer):
> 
> > See https://goo.gl/tpsmEJ for details.
> > Please credit me with: Reported-by: syzbot 
> > syzbot will keep track of this bug report.
> > To mark this as a duplicate of another syzbot report, please reply with:
> > #syz dup: exact-subject-of-another-report
> > Note: all commands must start from beginning of the line in the email body.

#syz dup: BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

Re: [rds-devel] BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

[Eric Biggers]

On Mon, Dec 18, 2017 at 12:22:51PM -0500, Sowmini Varadhan wrote:
> > From: Santosh Shilimkar 
> > Date: Mon, 18 Dec 2017 08:28:05 -0800
>   :
> > > Looks like another one tripping on empty transport. Mostly below
> > > should
> > > address it but we will test it if it does.
> 
> that was my first thought, but it cannot be the case here: rds_sendmsg
> etc itself would have bombed if that were the case, and the packet
> would never have gotten queued.
> 
> This is unlike f3069c6d33, where an applications skips the transport
> binding (either misses the explicit bind, or gets the wrong transport
> due to an implicit bind) before it triggers the setsockopt.
> 
> I suspect that the problems is that the conn (and thus c_trans)
> have gotten destroyed, but the cp_send_w work got incorrectly 
> re-queued. For example, rds_cong_queue_updates() (because the
> peer sent a congestion update) can happen in softirq context, 
> and would end up requeing work in the middle of rds_conn_destroy, 
> after we have assumed that everything is quisced.
> 
> On (12/18/17 12:12), David Miller wrote:
> > 
> > We're seeming to accumulate a lot of checks like this, maybe there
> > is a more general way to deal with this problem?
> 
> Yeah, I was thinking about this..  let me try to reprodcue this in-house
> and get back with a patchset.  
> 

I assume you weren't able to reproduce this?  This crash hasn't been seen again,
and it was reported while KASAN was accidentally disabled in the syzbot kconfig
due to a change to the kconfig menus in linux-next.  So this crash was possibly
caused by slab corruption elsewhere.

I am invalidating the bug for syzbot so it will report the same crash signature
again if it occurs, but if you think there is a real bug feel free to keep
looking into it.

#syz invalid

Thanks,

Eric

Re: BUG: unable to handle kernel NULL pointer dereference in inet6_fill_ifinfo

[Eric Biggers]

On Mon, Dec 18, 2017 at 11:54:00PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at 022c
> IP: inet6_fill_ifinfo+0x8e/0x2c0 net/ipv6/addrconf.c:5357
> PGD 1dffd8067 P4D 1dffd8067 PUD 1dc705067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 27870 Comm: syz-executor2 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:inet6_fill_ifinfo+0x8e/0x2c0 net/ipv6/addrconf.c:5357
> RSP: 0018:c9f53ae0 EFLAGS: 00010216
> RAX: 000a RBX: 88021433b300 RCX: 8224ba71
> RDX: 0818 RSI: c9000457f000 RDI: 
> RBP: c9f53b18 R08: 0010 R09: 8801dac27ae0
> R10:  R11:  R12: 
> R13: 8801dfaf5c00 R14: 8801dac27ac0 R15: 0002
> FS:  7f0fb6e3b700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 022c CR3: 00021356 CR4: 001406f0
> DR0: 2000 DR1: 2000 DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  inet6_dump_ifinfo+0x1ea/0x2d0 net/ipv6/addrconf.c:5411
>  netlink_dump+0x14e/0x360 net/netlink/af_netlink.c:
>  __netlink_dump_start+0x1bb/0x210 net/netlink/af_netlink.c:2319
>  netlink_dump_start include/linux/netlink.h:214 [inline]
>  rtnetlink_rcv_msg+0x44f/0x5d0 net/core/rtnetlink.c:4485
>  netlink_rcv_skb+0x92/0x160 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x1d4/0x290 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0x345/0x470 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  SYSC_sendto+0x17f/0x1d0 net/socket.c:1727
>  SyS_sendto+0x40/0x50 net/socket.c:1695
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f0fb6e3ac58 EFLAGS: 0212 ORIG_RAX: 002c
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX: 0012 RSI: 20919000 RDI: 0013
> RBP: 0553 R08: 2000 R09: 
> R10:  R11: 0212 R12: 006f6068
> R13:  R14: 7f0fb6e3b6d4 R15: 
> Code: b8 10 00 00 00 48 89 df e8 d0 b2 ee ff 48 85 c0 49 89 c6 0f 84 c5 01
> 00 00 e8 cf e8 06 ff b8 0a 00 00 00 4c 89 e7 66 41 89 46 10 <41> 0f b7 84 24
> 2c 02 00 00 66 41 89 46 12 41 8b 84 24 08 01 00
> RIP: inet6_fill_ifinfo+0x8e/0x2c0 net/ipv6/addrconf.c:5357 RSP:
> c9f53ae0
> CR2: 022c
> ---[ end trace bb449c11e1e11a3c ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in snmp6_unregister_dev

[Eric Biggers]

On Tue, Dec 19, 2017 at 12:35:02AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at 0578
> IP: read_pnet include/net/net_namespace.h:270 [inline]
> IP: dev_net include/linux/netdevice.h:2041 [inline]
> IP: snmp6_unregister_dev+0x12/0x70 net/ipv6/proc.c:308
> PGD 1e261e067 P4D 1e261e067 PUD 1dc92e067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 1259 Comm: kworker/u4:3 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: netns cleanup_net
> RIP: 0010:read_pnet include/net/net_namespace.h:270 [inline]
> RIP: 0010:dev_net include/linux/netdevice.h:2041 [inline]
> RIP: 0010:snmp6_unregister_dev+0x12/0x70 net/ipv6/proc.c:308
> RSP: 0018:c90002cd3b28 EFLAGS: 00010293
> RAX:  RBX: 8801e0a90800 RCX: 822a18ef
> RDX:  RSI: 83164ac0 RDI: 8801e0a90800
> RBP: c90002cd3b38 R08:  R09: 
> R10: 0001 R11:  R12: 8801e0a90800
> R13: 8801e0a90800 R14: c90002cd3ce8 R15: 8801dc936000
> FS:  () GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0578 CR3: 0001dc8f1000 CR4: 001426e0
> Call Trace:
>  addrconf_ifdown+0x70e/0x780 net/ipv6/addrconf.c:3607
>  addrconf_notify+0x86/0xd50 net/ipv6/addrconf.c:3514
>  notifier_call_chain+0x41/0xc0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1679
>  call_netdevice_notifiers net/core/dev.c:1697 [inline]
>  rollback_registered_many+0x330/0x490 net/core/dev.c:7288
>  unregister_netdevice_many.part.117+0x17/0x90 net/core/dev.c:8330
>  unregister_netdevice_many+0x22/0x30 net/core/dev.c:8329
>  ip6_tnl_exit_batch_net+0x276/0x380 net/ipv6/ip6_tunnel.c:2240
>  ops_exit_list.isra.6+0x70/0x80 net/core/net_namespace.c:145
>  cleanup_net+0x210/0x350 net/core/net_namespace.c:484
>  process_one_work+0x288/0x7a0 kernel/workqueue.c:2112
>  worker_thread+0x43/0x4d0 kernel/workqueue.c:2246
>  kthread+0x149/0x170 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> Code: fe ff ff ff eb e4 bb f4 ff ff ff eb dd 66 90 66 2e 0f 1f 84 00 00 00
> 00 00 55 48 89 e5 41 54 53 48 89 fb e8 51 8a 01 ff 48 8b 03 <48> 8b 80 78 05
> 00 00 48 83 b8 18 02 00 00 00 74 3e e8 38 8a 01
> RIP: read_pnet include/net/net_namespace.h:270 [inline] RSP:
> c90002cd3b28
> RIP: dev_net include/linux/netdevice.h:2041 [inline] RSP: c90002cd3b28
> RIP: snmp6_unregister_dev+0x12/0x70 net/ipv6/proc.c:308 RSP:
> c90002cd3b28
> CR2: 0578
> ---[ end trace b3ddb42264b96238 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in ip_mc_up

[Eric Biggers]

On Tue, Dec 19, 2017 at 12:40:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> netlink: 29 bytes leftover after parsing attributes in process
> `syz-executor2'.
> device eql entered promiscuous mode
> BUG: unable to handle kernel NULL pointer dereference at 0578
> IP: read_pnet include/net/net_namespace.h:270 [inline]
> IP: dev_net include/linux/netdevice.h:2041 [inline]
> IP: ip_mc_up+0x15/0x170 net/ipv4/igmp.c:1736
> PGD 1df61f067 P4D 1df61f067 PUD 1de8fc067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 23740 Comm: syz-executor6 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> netlink: 29 bytes leftover after parsing attributes in process
> `syz-executor2'.
> RIP: 0010:read_pnet include/net/net_namespace.h:270 [inline]
> RIP: 0010:dev_net include/linux/netdevice.h:2041 [inline]
> RIP: 0010:ip_mc_up+0x15/0x170 net/ipv4/igmp.c:1736
> RSP: 0018:c900010abb88 EFLAGS: 00010212
> RAX:  RBX: 0001 RCX: 821dd421
> RDX: 235e RSI: c900035dd000 RDI: 8801df56d000
> RBP: c900010abba0 R08:  R09: 
> R10: c900010abc20 R11:  R12: 8801df56d000
> R13: 8801df652000 R14:  R15: 8801df56d000
> FS:  7f4c60214700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0578 CR3: 0001dc7f1000 CR4: 001426f0
> Call Trace:
>  inetdev_event+0x224/0x5c0 net/ipv4/devinet.c:1504
>  notifier_call_chain+0x41/0xc0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1679
>  call_netdevice_notifiers net/core/dev.c:1697 [inline]
>  __dev_notify_flags+0x75/0x130 net/core/dev.c:6874
>  dev_change_flags+0x5e/0x70 net/core/dev.c:6910
>  devinet_ioctl+0x77b/0x930 net/ipv4/devinet.c:1083
>  inet_ioctl+0xda/0x130 net/ipv4/af_inet.c:902
>  sock_do_ioctl+0x2c/0x60 net/socket.c:964
>  sock_ioctl+0x211/0x320 net/socket.c:1061
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f4c60213c58 EFLAGS: 0212 ORIG_RAX: 0010
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX: 2062ffe0 RSI: 8914 RDI: 0016
> RBP: 026a R08:  R09: 
> R10:  R11: 0212 R12: 006f1a90
> R13:  R14: 7f4c602146d4 R15: 
> Code: c7 90 cf e5 82 e8 44 04 06 ff e8 dc e2 3c 00 e9 64 ff ff ff 66 90 55
> 48 89 e5 41 55 41 54 53 49 89 fc e8 1f cf 0d ff 49 8b 04 24 <48> 8b 98 78 05
> 00 00 e8 ff c6 f0 ff 85 c0 0f 84 17 01 00 00 e8
> RIP: read_pnet include/net/net_namespace.h:270 [inline] RSP:
> c900010abb88
> RIP: dev_net include/linux/netdevice.h:2041 [inline] RSP: c900010abb88
> RIP: ip_mc_up+0x15/0x170 net/ipv4/igmp.c:1736 RSP: c900010abb88
> CR2: 0578
> ---[ end trace 41722ce46f86bba0 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in tc_fill_qdisc

[Eric Biggers]

On Tue, Dec 19, 2017 at 04:49:02AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: qdisc_dev include/net/sch_generic.h:379 [inline]
> IP: tc_fill_qdisc+0xc8/0x4b0 net/sched/sch_api.c:792
> PGD 1dc5d4067 P4D 1dc5d4067 PUD 1db5fa067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 7609 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:qdisc_dev include/net/sch_generic.h:379 [inline]
> RIP: 0010:tc_fill_qdisc+0xc8/0x4b0 net/sched/sch_api.c:792
> RSP: 0018:c9ea38c8 EFLAGS: 00010212
> RAX:  RBX: 880216ac3c00 RCX: 8212563c
> RDX: 0a02 RSI: c90004f53000 RDI: 8801dc6a20b0
> RBP: c9ea3970 R08: 0014 R09: 8801dc6a20b0
> R10: c9ea37d8 R11: 0002 R12: 880214161b00
> R13: 8801dc6a208c R14:  R15: 0002
> FS:  7f6db5bc5700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0001dc75a000 CR4: 001426f0
> DR0: 2000 DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  tc_dump_qdisc_root+0x1f1/0x220 net/sched/sch_api.c:1474
>  tc_dump_qdisc+0x1a1/0x280 net/sched/sch_api.c:1540
>  netlink_dump+0x14e/0x360 net/netlink/af_netlink.c:
>  __netlink_dump_start+0x1bb/0x210 net/netlink/af_netlink.c:2319
>  netlink_dump_start include/linux/netlink.h:214 [inline]
>  rtnetlink_rcv_msg+0x44f/0x5d0 net/core/rtnetlink.c:4485
>  netlink_rcv_skb+0x92/0x160 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x1d4/0x290 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0x345/0x470 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  ___sys_sendmsg+0x35e/0x3b0 net/socket.c:2026
>  __sys_sendmsg+0x50/0x90 net/socket.c:2060
>  SYSC_sendmsg net/socket.c:2071 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2067
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f6db5bc4c58 EFLAGS: 0212 ORIG_RAX: 002e
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX:  RSI: 2061efc8 RDI: 001c
> RBP: 0343 R08:  R09: 
> R10:  R11: 0212 R12: 006f2ee8
> R13:  R14: 7f6db5bc56d4 R15: 
> Code: 41 b8 14 00 00 00 4c 89 e7 e8 05 17 01 00 48 85 c0 49 89 c5 0f 84 cb
> 02 00 00 e8 04 4d 19 ff 41 c7 45 10 00 00 00 00 48 8b 43 40 <48> 8b 00 8b 80
> 08 01 00 00 45 89 75 1c 41 89 45 14 8b 43 38 41
> RIP: qdisc_dev include/net/sch_generic.h:379 [inline] RSP: c9ea38c8
> RIP: tc_fill_qdisc+0xc8/0x4b0 net/sched/sch_api.c:792 RSP: c9ea38c8
> CR2: 
> ---[ end trace dffd1876816a33a6 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in qdisc_match_from_root

[Eric Biggers]

On Tue, Dec 19, 2017 at 05:43:00AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> netlink: 1 bytes leftover after parsing attributes in process
> `syz-executor6'.
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: qdisc_dev include/net/sch_generic.h:379 [inline]
> IP: qdisc_match_from_root+0x19/0xd0 net/sched/sch_api.c:266
> PGD 1db153067 P4D 1db153067 PUD 1da621067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 15445 Comm: syz-executor5 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:qdisc_dev include/net/sch_generic.h:379 [inline]
> RIP: 0010:qdisc_match_from_root+0x19/0xd0 net/sched/sch_api.c:266
> RSP: 0018:c9dafac8 EFLAGS: 00010216
> RAX:  RBX: 8801de311c00 RCX: 82123f94
> RDX: 027f RSI: c90004086000 RDI: 8801db4de400
> RBP: c9dafae0 R08:  R09: c9dafb30
> R10: c9dafbb8 R11: 0004 R12: 8801db4de400
> R13: 0500 R14: 8801dfa1e1c0 R15: 0500
> FS:  7f98eef31700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0001da7ef000 CR4: 001406f0
> DR0: 2000 DR1: 2000 DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  qdisc_lookup+0x2d/0x140 net/sched/sch_api.c:306
>  tc_get_qdisc+0xe2/0x380 net/sched/sch_api.c:1259
>  rtnetlink_rcv_msg+0x333/0x5d0 net/core/rtnetlink.c:4522
>  netlink_rcv_skb+0x92/0x160 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x1d4/0x290 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0x345/0x470 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  sock_write_iter+0xa4/0x100 net/socket.c:915
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x15b/0x1e0 fs/read_write.c:482
>  vfs_write+0xf0/0x230 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0x57/0xd0 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f98eef30c58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX: 005e RSI: 20fab000 RDI: 0013
> RBP: 039b R08:  R09: 
> R10:  R11: 0212 R12: 006f3728
> R13:  R14: 7f98eef316d4 R15: 
> Code: 49 c7 c4 28 76 ff 83 eb dd 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 41
> 55 41 54 53 49 89 fc 41 89 f5 e8 ac 63 19 ff 49 8b 44 24 40 <48> 8b 18 48 85
> db 0f 84 8b 00 00 00 e8 96 63 19 ff 41 f6 44 24
> RIP: qdisc_dev include/net/sch_generic.h:379 [inline] RSP: c9dafac8
> RIP: qdisc_match_from_root+0x19/0xd0 net/sched/sch_api.c:266 RSP:
> c9dafac8
> CR2: 
> ---[ end trace c23e90bc7d735c44 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_get_lladdr

[Eric Biggers]

On Tue, Dec 19, 2017 at 08:38:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> device lo entered promiscuous mode
> device lo left promiscuous mode
> BUG: unable to handle kernel NULL pointer dereference at 0328
> IP: __read_once_size include/linux/compiler.h:183 [inline]
> IP: __in6_dev_get include/net/addrconf.h:300 [inline]
> IP: ipv6_get_lladdr+0x6f/0x270 net/ipv6/addrconf.c:1813
> PGD 0 P4D 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 16588 Comm: syz-executor1 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:183 [inline]
> RIP: 0010:__in6_dev_get include/net/addrconf.h:300 [inline]
> RIP: 0010:ipv6_get_lladdr+0x6f/0x270 net/ipv6/addrconf.c:1813
> RSP: 0018:88021fd03da8 EFLAGS: 00010206
> RAX: 8801fcb0a280 RBX:  RCX: 8225359f
> RDX: 0100 RSI: aa440f11 RDI: 0286
> RBP: 88021fd03de0 R08: 0001 R09: 0002
> R10: 88021fd03d30 R11: 0002 R12: 8802156f2000
> R13: 0040 R14:  R15: 
> FS:  () GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0328 CR3: 0301e002 CR4: 001606e0
> Call Trace:
>  
>  addrconf_rs_timer+0x128/0x230 net/ipv6/addrconf.c:3762
>  call_timer_fn+0x9f/0x3f0 kernel/time/timer.c:1320
>  expire_timers kernel/time/timer.c:1357 [inline]
>  __run_timers kernel/time/timer.c:1660 [inline]
>  run_timer_softirq+0x68a/0x830 kernel/time/timer.c:1686
>  __do_softirq+0xcb/0x4f3 kernel/softirq.c:285
>  invoke_softirq kernel/softirq.c:365 [inline]
>  irq_exit+0xd4/0xe0 kernel/softirq.c:405
>  exiting_irq arch/x86/include/asm/apic.h:540 [inline]
>  smp_apic_timer_interrupt+0x8e/0x2a0 arch/x86/kernel/apic/apic.c:1052
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>  
> RIP: 0010:lock_acquire+0x21/0x220 kernel/locking/lockdep.c:3906
> RSP: 0018:c9ee79f8 EFLAGS: 0292 ORIG_RAX: ff11
> RAX: 8801fcb0a280 RBX: ea00084e2340 RCX: 0002
> RDX:  RSI:  RDI: 83080740
> RBP: c9ee7a38 R08:  R09: 
> R10:  R11: 8801fcb0a280 R12: ea00084e2340
> R13: ea00084e2340 R14:  R15: 
>  rcu_lock_acquire include/linux/rcupdate.h:244 [inline]
>  rcu_read_lock include/linux/rcupdate.h:630 [inline]
>  lock_page_memcg+0x33/0xf0 mm/memcontrol.c:1620
>  page_remove_file_rmap mm/rmap.c:1213 [inline]
>  page_remove_rmap+0x12e/0x4b0 mm/rmap.c:1298
>  zap_pte_range mm/memory.c:1337 [inline]
>  zap_pmd_range mm/memory.c:1441 [inline]
>  zap_pud_range mm/memory.c:1470 [inline]
>  zap_p4d_range mm/memory.c:1491 [inline]
>  unmap_page_range+0x86f/0xed0 mm/memory.c:1512
>  unmap_single_vma+0xbb/0x140 mm/memory.c:1557
>  unmap_vmas+0x65/0xd0 mm/memory.c:1587
>  exit_mmap+0xb0/0x1e0 mm/mmap.c:3020
>  __mmput kernel/fork.c:966 [inline]
>  mmput+0x82/0x190 kernel/fork.c:987
>  exit_mm kernel/exit.c:544 [inline]
>  do_exit+0x356/0x1050 kernel/exit.c:856
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  get_signal+0x36c/0xad0 kernel/signal.c:2337
>  do_signal+0x23/0x670 arch/x86/kernel/signal.c:809
>  exit_to_usermode_loop+0x13c/0x160 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x1b4/0x1e0 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x452a09
> RSP: 002b:7f96787f3ce8 EFLAGS: 0246 ORIG_RAX: 00ca
> RAX: fe00 RBX: 0071c0f0 RCX: 00452a09
> RDX:  RSI:  RDI: 0071c0f0
> RBP: 0071c0f0 R08: 0422 R09: 0071c0c8
> R10:  R11: 0246 R12: 
> R13: 00a2f7ff R14: 7f96787f49c0 R15: 0006
> Code: c7 40 07 08 83 e8 b2 2e fd fe e8 3d 9e ff fe 85 c0 5a 74 12 e8 b3 6d
> 06 ff 80 3d 73 10 f6 00 00 0f 84 7a 01 00 00 e8 a1 6d 06 ff <4c> 8b a3 28 03
> 00 00 e8 15 9e ff fe 85 c0 74 12 e8 8c 6d 06 ff
> RIP: __read_once_size include/linux/compiler.h:183 [inline] RSP:
> 88021fd03da8
> RIP: __in6_dev_get include/net/addrconf.h:300 [inline] RSP: 88021fd03da8
> RIP: ipv6_get_lladdr+0x6f/0x270 net/ipv6/addrconf.c:1813 RSP:
> 88021fd03da8
> CR2: 0328
> ---[ end trace cc2639f5bc6e4363 ]---

Invalidating this bug 

Re: BUG: unable to handle kernel NULL pointer dereference in neigh_fill_info

[Eric Biggers]

On Tue, Dec 19, 2017 at 10:41:00AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> netlink: 3 bytes leftover after parsing attributes in process
> `syz-executor5'.
> netlink: 3 bytes leftover after parsing attributes in process
> `syz-executor5'.
> BUG: unable to handle kernel NULL pointer dereference at 0008
> sock: process `syz-executor4' is using obsolete getsockopt SO_BSDCOMPAT
> IP: neigh_fill_info+0xe6/0x460 net/core/neighbour.c:2218
> PGD 1dece0067 P4D 1dece0067 PUD 1dc5b9067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 25561 Comm: syz-executor5 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:neigh_fill_info+0xe6/0x460 net/core/neighbour.c:2218
> RSP: 0018:c9eaf9d0 EFLAGS: 00010246
> RAX:  RBX: 88021568b000 RCX: 88021568b288
> RDX:  RSI: 0001 RDI: 880215753800
> RBP: c9eafa40 R08: 000c R09: 88020ff500b4
> R10: c9eaf9d8 R11: 0002 R12: 88020ff50098
> R13: 93f7 R14: 001c R15: 880215753800
> FS:  7f91a7086700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0008 CR3: 0001df751000 CR4: 001426f0
> DR0: 2008 DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 00030602
> Call Trace:
>  neigh_dump_table net/core/neighbour.c:2350 [inline]
>  neigh_dump_info+0x532/0x9d0 net/core/neighbour.c:2438
>  netlink_dump+0x14e/0x360 net/netlink/af_netlink.c:
>  __netlink_dump_start+0x1bb/0x210 net/netlink/af_netlink.c:2319
>  netlink_dump_start include/linux/netlink.h:214 [inline]
>  rtnetlink_rcv_msg+0x44f/0x5d0 net/core/rtnetlink.c:4485
>  netlink_rcv_skb+0x92/0x160 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x1d4/0x290 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0x345/0x470 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  sock_write_iter+0xa4/0x100 net/socket.c:915
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x15b/0x1e0 fs/read_write.c:482
>  vfs_write+0xf0/0x230 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0x57/0xd0 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f91a7085c58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: 7f91a7086700 RCX: 00452a39
> RDX: 001f RSI: 2083a000 RDI: 0017
> RBP:  R08:  R09: 
> R10:  R11: 0212 R12: 
> R13: 00a6f7ff R14: 7f91a70869c0 R15: 
> Code: 14 01 00 00 41 88 44 24 1a 0f b6 83 16 01 00 00 41 88 44 24 1b 48 8b
> 83 80 02 00 00 8b 80 08 01 00 00 41 89 44 24 14 48 8b 43 08 <8b> 50 08 e8 c2
> e3 68 ff 85 c0 0f 85 5d 02 00 00 4c 8d 73 28 e8
> RIP: neigh_fill_info+0xe6/0x460 net/core/neighbour.c:2218 RSP:
> c9eaf9d0
> CR2: 0008
> ---[ end trace fd0910621fa1f590 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in addrconf_notify

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:48:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> ALSA: seq fatal error: cannot create timer (-22)
> device syz2 entered promiscuous mode
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: addrconf_permanent_addr net/ipv6/addrconf.c:3351 [inline]
> IP: addrconf_notify+0x7df/0xd50 net/ipv6/addrconf.c:3422
> PGD 1fad11067 P4D 1fad11067 PUD 1fad7a067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 15171 Comm: syz-executor2 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:addrconf_permanent_addr net/ipv6/addrconf.c:3351 [inline]
> RIP: 0010:addrconf_notify+0x7df/0xd50 net/ipv6/addrconf.c:3422
> RSP: 0018:c9d63b80 EFLAGS: 00010282
> RAX:  RBX: 8801fa41a000 RCX: 8801faddd808
> RDX: 00ff RSI: 2811d9a2 RDI: 8801faddd968
> RBP: c9d63c00 R08: 0001 R09: 0004
> R10: c9d63af0 R11: 0004 R12: 0001
> R13: 8801faddd800 R14:  R15: 8801faddd800
> FS:  7f4373896700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0002143c4001 CR4: 001606f0
> DR0: 2008 DR1: 2000 DR2: 2000
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  notifier_call_chain+0x41/0xc0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1679
>  call_netdevice_notifiers net/core/dev.c:1697 [inline]
>  __dev_notify_flags+0x75/0x130 net/core/dev.c:6874
>  dev_change_flags+0x5e/0x70 net/core/dev.c:6910
>  devinet_ioctl+0x77b/0x930 net/ipv4/devinet.c:1083
>  inet_ioctl+0xda/0x130 net/ipv4/af_inet.c:902
>  sock_do_ioctl+0x2c/0x60 net/socket.c:964
>  sock_ioctl+0x211/0x320 net/socket.c:1061
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a09
> RSP: 002b:7f4373895c58 EFLAGS: 0212 ORIG_RAX: 0010
> RAX: ffda RBX: 0071bea0 RCX: 00452a09
> RDX: 2062ffe0 RSI: 8914 RDI: 0013
> RBP: 02eb R08:  R09: 
> R10:  R11: 0212 R12: 006f16a8
> R13:  R14: 7f43738966d4 R15: 
> Code: 85 ed 0f 84 f4 00 00 00 e8 ff 3a 06 ff 49 8d 85 68 01 00 00 48 89 c7
> 48 89 45 a8 e8 0c 9f 37 00 49 8b 45 08 4c 89 e9 48 83 c1 08 <48> 8b 38 48 39
> c1 4c 8d a8 c8 fe ff ff 4c 8d a7 c8 fe ff ff 0f
> RIP: addrconf_permanent_addr net/ipv6/addrconf.c:3351 [inline] RSP:
> c9d63b80
> RIP: addrconf_notify+0x7df/0xd50 net/ipv6/addrconf.c:3422 RSP:
> c9d63b80
> CR2: 
> ---[ end trace ebbf2e3971cab1b5 ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_cmp_addr_exact

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:49:03PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> binder: 23647:23660 DecRefs 0 refcount change on invalid ref 4 ret -22
> binder: 23647:23660 BC_CLEAR_DEATH_NOTIFICATION invalid ref 0
> binder: 23647:23660 BC_REQUEST_DEATH_NOTIFICATION invalid ref 3
> binder: 23647:23660 got reply transaction with no transaction stack
> binder: 23647:23660 transaction failed 29201/-71, size 24-16 line 2747
> BUG: unable to handle kernel NULL pointer dereference at 0078
> IP: sctp_cmp_addr_exact+0x14/0x60 net/sctp/associola.c:911
> PGD 1dde2b067 P4D 1dde2b067 PUD 1ddf17067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 23653 Comm: syz-executor1 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:sctp_cmp_addr_exact+0x14/0x60 net/sctp/associola.c:911
> RSP: 0018:c9da7b38 EFLAGS: 00010216
> RAX: 0001 RBX: fff0 RCX: 823e3464
> RDX: 0731 RSI: c90003199000 RDI: 0078
> RBP: c9da7b50 R08: 0001 R09: 0002
> R10: c9da7b18 R11: 0002 R12: 0078
> R13: 8801d9231488 R14: c9da7bc8 R15: 831e6c20
> FS:  7f601f498700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0078 CR3: 0001d9071000 CR4: 001426f0
> DR0: 2008 DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  sctp_hash_cmp+0x2b/0xb0 net/sctp/input.c:807
>  __rhashtable_lookup include/linux/rhashtable.h:633 [inline]
>  rhltable_lookup include/linux/rhashtable.h:716 [inline]
>  sctp_hash_transport+0x179/0xb00 net/sctp/input.c:890
>  sctp_assoc_add_peer+0x31d/0x450 net/sctp/associola.c:718
>  sctp_sendmsg+0xd59/0x14d0 net/sctp/socket.c:1921
>  inet_sendmsg+0x54/0x250 net/ipv4/af_inet.c:763
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  SYSC_sendto+0x17f/0x1d0 net/socket.c:1727
>  SyS_sendto+0x40/0x50 net/socket.c:1695
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f601f497c58 EFLAGS: 0212 ORIG_RAX: 002c
> RAX: ffda RBX: 007580d8 RCX: 00452a39
> RDX: 0001 RSI: 20aaff09 RDI: 001a
> RBP: 03a1 R08: 2030bfe4 R09: 001c
> R10:  R11: 0212 R12: 006f37b8
> R13:  R14: 7f601f4986d4 R15: 0002
> Code: 00 01 8d 50 01 89 93 34 06 00 00 5b 5d c3 66 0f 1f 84 00 00 00 00 00
> 55 48 89 e5 41 55 41 54 53 49 89 fc 49 89 f5 e8 dc 6e ed fe <41> 0f b7 3c 24
> e8 92 e3 ff ff 48 85 c0 74 21 48 89 c3 e8 c5 6e
> RIP: sctp_cmp_addr_exact+0x14/0x60 net/sctp/associola.c:911 RSP:
> c9da7b38
> CR2: 0078
> ---[ end trace 436f7126566693ea ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in addrconf_ifdown

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:50:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: addrconf_ifdown+0x3a2/0x780 net/ipv6/addrconf.c:3674
> PGD 1df99c067 P4D 1df99c067 PUD 1dfbbe067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 28113 Comm: syz-executor0 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:addrconf_ifdown+0x3a2/0x780 net/ipv6/addrconf.c:3674
> RSP: 0018:c900014bf928 EFLAGS: 00010293
> RAX:  RBX:  RCX: 82251944
> RDX: 880216be6808 RSI: 880216be69b8 RDI: 0001
> RBP: c900014bf980 R08:  R09: 
> R10:  R11:  R12: 880216be6800
> R13: 880216be6968 R14:  R15: 831755a0
> FS:  7f91d886d700() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0001df119000 CR4: 001426f0
> DR0: 2000 DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  addrconf_notify+0x86/0xd50 net/ipv6/addrconf.c:3514
>  notifier_call_chain+0x41/0xc0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1679
>  call_netdevice_notifiers net/core/dev.c:1697 [inline]
>  dev_close_many+0x121/0x190 net/core/dev.c:1492
>  rollback_registered_many+0x16f/0x490 net/core/dev.c:7265
>  rollback_registered+0x59/0x90 net/core/dev.c:7330
>  unregister_netdevice_queue+0xa5/0xf0 net/core/dev.c:8311
>  unregister_netdevice include/linux/netdevice.h:2464 [inline]
>  __tun_detach+0x618/0x680 drivers/net/tun.c:688
>  tun_detach drivers/net/tun.c:699 [inline]
>  tun_chr_close+0x26/0x30 drivers/net/tun.c:2955
>  __fput+0x120/0x270 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:243
>  task_work_run+0xa3/0xe0 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x3e6/0x1050 kernel/exit.c:869
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  get_signal+0x36c/0xad0 kernel/signal.c:2337
>  do_signal+0x23/0x670 arch/x86/kernel/signal.c:809
>  exit_to_usermode_loop+0x13c/0x160 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x1b4/0x1e0 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f91d886cc58 EFLAGS: 0212 ORIG_RAX: 0010
> RAX:  RBX: 007580d8 RCX: 00452a39
> RDX:  RSI: 4c06 RDI: 001c
> RBP: 02dc R08:  R09: 
> R10:  R11: 0212 R12: 006f2540
> R13:  R14: 7f91d886d6d4 R15: 0012
> Code: 17 e8 13 8a 06 ff 41 8b b4 24 50 02 00 00 31 c0 85 f6 0f 94 c0 89 45
> d0 e8 fc 89 06 ff 49 8b 44 24 08 49 8d 54 24 08 48 89 55 b8 <48> 8b 08 48 39
> d0 48 8d 98 c8 fe ff ff 48 89 45 c0 4c 8d b1 c8
> RIP: addrconf_ifdown+0x3a2/0x780 net/ipv6/addrconf.c:3674 RSP:
> c900014bf928
> CR2: 
> ---[ end trace 36c3336430e0eeeb ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)

[Eric Biggers]

On Wed, Dec 13, 2017 at 06:18:05AM +0100, Steffen Klassert wrote:
> On Tue, Dec 12, 2017 at 01:00:31PM -0800, Eric Biggers wrote:
> > Hi Steffen,
> > 
> > On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote:
> > > On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> > > > syzkaller has found reproducer for the following crash on
> > > > 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> > > > compiler: gcc (GCC) 7.1.1 20170620
> > > > .config is attached
> > > > Raw console output is attached.
> > > > C reproducer is attached
> > > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > > for information about syzkaller reproducers
> > > > 
> > > > 
> > > > BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> > > > net/xfrm/xfrm_state.c:1051
> > > > Read of size 4 at addr 8801ccaa7af8 by task syzkaller231684/3045
> > > 
> > > The patch below should fix this. I plan to apply it to the ipsec tree
> > > after some advanced testing.
> > > 
> > > Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured 
> > > transport
> > >  mode policies.
> > > 
> > 
> > Are you still planning to apply this?  syzbot is still hitting this bug.
> 
> It is already applied to the ipsec tree, will go upstream by the end of
> this week.
>

Marking this fixed for syzbot:

#syz fix: xfrm: Fix stack-out-of-bounds with misconfigured transport mode 
policies.

Re: WARNING in xfrm_state_fini

[Eric Biggers]

On Mon, Nov 27, 2017 at 09:37:07AM -0800, Cong Wang wrote:
> On Mon, Nov 27, 2017 at 3:55 AM, Steffen Klassert
>  wrote:
> > On Tue, Nov 21, 2017 at 06:44:04PM -0800, Cong Wang wrote:
> >> User-space uses proto==0 as a wildcard, but xfrm_id_proto_match()
> >> doesn't consider it as a match with IPSEC_PROTO_ANY, in this case
> >> it should match all. Not sure if the following patch is the best way to
> >> fix it, or perhaps x->id.proto should be initialized to some of these 3
> >> values, but looking into ->init_temprop() it is not the case.
> >
> > x->id is copied from the policy template and it seems that we don't
> > validate the id of the template when inserting the policy. iproute2
> > checks for a valid IPsec proto but the kernel does not do so. I think
> > we should check the policy template and reject inserting if the proto
> > is invalid.
> >
> 
> Oh, I thought 0 is used as wildcard, so it is not.
> 
> Something like below?
> 
> @@ -1445,6 +1446,15 @@ static int validate_tmpl(int nr, struct
> xfrm_user_tmpl *ut, u16 family)
> default:
> return -EINVAL;
> }
> +   switch (ut[i].id.proto) {
> +   case IPPROTO_AH:
> +   case IPPROTO_ESP:
> +   case IPPROTO_COMP:
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> }
> 
> return 0;
> 

I assume this is supposed to be fixed by the following, so marking it closed for
syzbot:

#syz fix: xfrm: check id proto in validate_tmpl()

But syzbot has been hitting a WARN_ON() in xfrm_state_fini() even after that
fix, so it should get reported as a new bug.

Re: general protection fault in __rds_rdma_map

[Eric Biggers]

On Mon, Nov 27, 2017 at 10:30:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> e1d1ea549b57790a3d8cf6300e6ef86118d692a3
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> RDS: rds_bind could not find a transport for 224.0.0.2, load rds_tcp or
> rds_rdma?
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3078 Comm: syzkaller719569 Not tainted 4.14.0+ #189
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> task: 8801cbbda580 task.stack: 8801cb8d
> RIP: 0010:__rds_rdma_map+0x133/0x1050 net/rds/rdma.c:191
> RSP: 0018:8801cb8d7a28 EFLAGS: 00010206
> RAX: dc00 RBX: 8801cb8d7bd0 RCX: 84c0b20d
> RDX: 0018 RSI: 8801cb8d7bd0 RDI: 00c0
> RBP: 8801cb8d7b90 R08: ed003971af96 R09: ed003971af96
> R10:  R11: ed003971af95 R12: 
> R13: 8801cb407480 R14:  R15: 8801cb407480
> FS:  7fb0be5a3700() GS:8801db50() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fb0be5a2e78 CR3: 0001cfc07000 CR4: 001406e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  rds_get_mr_for_dest+0x1bb/0x290 net/rds/rdma.c:357
>  rds_setsockopt+0x6b9/0x970 net/rds/af_rds.c:347
>  SYSC_setsockopt net/socket.c:1851 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1830
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x44a789
> RSP: 002b:7fb0be5a2dc8 EFLAGS: 0202 ORIG_RAX: 0036
> RAX: ffda RBX:  RCX: 0044a789
> RDX: 0007 RSI: 4114 RDI: 0004
> RBP: 0086 R08: 00a0 R09: 7fb0be5a3700
> R10: 2ffc R11: 0202 R12: 
> R13: 007efe3f R14: 7fb0be5a39c0 R15: 
> Code: 57 0d 00 00 48 8b 85 f0 fe ff ff 4c 8b a0 c0 04 00 00 48 b8 00 00 00
> 00 00 fc ff df 49 8d bc 24 c0 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 6a 0e 00 00 49 83 bc 24 c0 00 00 00 00 0f 84
> RIP: __rds_rdma_map+0x133/0x1050 net/rds/rdma.c:191 RSP: 8801cb8d7a28
> ---[ end trace 5e0e31770c7b70a7 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title

Crash is no longer occurring, apparently was fixed by:

#syz fix: rds: Fix NULL pointer dereference in __rds_rdma_map

Re: general protection fault in __lock_acquire (2)

[Eric Biggers]

On Thu, Nov 02, 2017 at 03:55:00AM -0700, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> fa8785e862ef644f742558f1a8c91eca6f3f0004
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> 
> 
> 
> R10: 20869000 R11: 0246 R12: 004a96f0
> R13:  R14: 7fe1d40269c8 R15: 7fe1d4026b38
> Subscriber rejected, no memory
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 3 PID: 16314 Comm: syz-executor6 Not tainted 4.14.0-rc7-next-20171102+
> #9
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003d54a000 task.stack: 880038f7
> RIP: 0010:__lock_acquire+0xdac/0x4770 kernel/locking/lockdep.c:3378
> RSP: 0018:880038f77328 EFLAGS: 00010002
> RAX: dc00 RBX:  RCX: 
> RDX: 0004 RSI:  RDI: 85ecb380
> RBP: 880038f77830 R08: 0001 R09: 
> R10:  R11: 8744cca0 R12: 88003d54a000
> R13:  R14: 0001 R15: 0020
> FS:  7fe1d4027700() GS:88006df0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fbbb18db000 CR3: 6a863000 CR4: 26e0
> Call Trace:
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:4004
>  __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
>  _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:173
>  spin_lock_bh include/linux/spinlock.h:319 [inline]
>  tipc_subscrb_subscrp_delete+0x8f/0x480 net/tipc/subscr.c:201
>  tipc_subscrb_delete net/tipc/subscr.c:238 [inline]
>  tipc_subscrb_release_cb+0x17/0x30 net/tipc/subscr.c:316
>  tipc_close_conn+0x171/0x270 net/tipc/server.c:204
>  tipc_topsrv_kern_subscr+0x724/0x810 net/tipc/server.c:514
>  tipc_group_create+0x702/0x9c0 net/tipc/group.c:184
>  tipc_sk_join net/tipc/socket.c:2747 [inline]
>  tipc_setsockopt+0x249/0xc10 net/tipc/socket.c:2861
>  SYSC_setsockopt net/socket.c:1851 [inline]
>  SyS_setsockopt+0x189/0x360 net/socket.c:1830
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x447c89
> RSP: 002b:7fe1d4026bd8 EFLAGS: 0246 ORIG_RAX: 0036
> RAX: ffda RBX: 7fe1d40276cc RCX: 00447c89
> RDX: 0087 RSI: 010f RDI: 0013
> RBP: 0086 R08: 0010 R09: 
> R10: 20869000 R11: 0246 R12: 004a96f0
> R13:  R14: 7fe1d40269c8 R15: 7fe1d4026b38
> Code: e9 03 f3 48 ab 48 81 c4 e0 04 00 00 44 89 f0 5b 41 5c 41 5d 41 5e 41
> 5f 5d c3 4c 89 fa 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
> 85 bf 33 00 00 49 81 3f 80 87 87 86 41 be 00 00
> RIP: __lock_acquire+0xdac/0x4770 kernel/locking/lockdep.c:3378 RSP:
> 880038f77328
> ---[ end trace 61ded41cffc497c5 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
> 
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title

No longer occurring, seems to have been fixed by:

#syz fix: tipc: fix a null pointer deref on error path

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Eric Biggers]

On Wed, Jan 17, 2018 at 05:18:17PM -0800, Joe Perches wrote:
> On Wed, 2018-01-17 at 20:09 -0500, Theodore Ts'o wrote:
> > get_maintainer.pl, which is often not accurate
> 
> Examples please.
> 

Well, the primary problem is that place the crash occurs is not necessarily
responsible for the bug.  But, syzbot actually does have a file blacklist for
exactly that reason; see
https://github.com/google/syzkaller/blob/master/pkg/report/linux.go#L56

It definitely needs further improvement (and anyone is welcome to contribute),
though it will never be perfect.  

There is also a KASAN change by Dmitry queued up for 4.16 that will allow KASAN
to detect invalid frees.  That would have detected the bug in crypto/pcrypt.c
that was causing corruption in the kmalloc-1024 slab cache, and was causing
crashes in all sorts of random kernel code, resulting many bug reports.  So,
detecting bugs early before they corrupt all sorts of random kernel data
structures helps a lot too.

And yes, get_maintainer.pl sometimes isn't accurate even if the offending code
is correctly identified.  That's more of a community problem, e.g. people
sometimes don't bother to remove themselves from MAINTAINERS when they quit
maintaining, and sometimes people don't feel responsible enough for a file to
add themselves to MAINTAINERS, even when in practice they are actually taking
most of the patches to it through their tree.

Eric