All of
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: syzbot <>
Cc: Andrew Morton <>,, David Miller <>,
	Florian Westphal <>, Jakub Jelinek <>,
	Lai Jiangshan <>,
	Jozsef Kadlecsik <>,
	Jakub Kicinski <>,
	Linux Kernel Mailing List <>,
	Netdev <>,
	NetFilter <>,
	Pablo Neira Ayuso <>,
	Peter Zijlstra <>,
	syzkaller-bugs <>,
	Tejun Heo <>
Subject: Re: kernel BUG at lib/string.c:LINE! (6)
Date: Tue, 22 Dec 2020 14:01:21 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Dec 22, 2020 at 6:44 AM syzbot
<> wrote:
> The issue was bisected to:
> commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")

That looks unlikely, although possibly some constant folding
improvement might make the fortify code notice something with it.

> detected buffer overflow in strlen
> ------------[ cut here ]------------
> kernel BUG at lib/string.c:1149!
> Call Trace:
>  strlen include/linux/string.h:325 [inline]
>  strlcpy include/linux/string.h:348 [inline]
>  xt_rateest_tg_checkentry+0x2a5/0x6b0 net/netfilter/xt_RATEEST.c:143

Honestly, this just looks like the traditional bug in "strlcpy()".

That BSD function is complete garbage, exactly because it doesn't
limit the source length. People tend to _think_ it does ("what's that
size_t argument for?") but strlcpy() only limits the *destination*
size, and the source is always read fully.

So it's a completely useless function if you can't implicitly trust
the source string - but that is almost always why people think they
should use it!

Nobody should use it. I really would like to remove it, and let
everybody know how incredibly broken sh*t that function is.

Can we please have everybody stop using strlcpy(). But in this
particular case, it's that xt_rateest_tg_checkentry() in

That said, this may be a real FORTIFY report if that info->name is
*supposed* to be trustworthy? The xt_RATETEST code does use
"info->name" a few lines earlier when it does

        est = __xt_rateest_lookup(xn, info->name);

or maybe the bisection is right, and this points to some problem with


  reply	other threads:[~2020-12-22 22:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22 14:44 kernel BUG at lib/string.c:LINE! (6) syzbot
2020-12-22 22:01 ` Linus Torvalds [this message]
2020-12-22 22:07   ` Florian Westphal
2020-12-23 11:25     ` Dmitry Vyukov
2020-12-22 22:23 ` [PATCH nf] netfilter: xt_RATEEST: reject non-null terminated string from userspace Florian Westphal
2020-12-22 22:29   ` Linus Torvalds
2020-12-22 22:50     ` Florian Westphal
2020-12-27 10:53   ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.