LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* WARNING in add_uevent_var
@ 2018-04-02  6:01 syzbot
  2018-04-03 12:34 ` Johannes Berg
  0 siblings, 1 reply; 3+ messages in thread
From: syzbot @ 2018-04-02  6:01 UTC (permalink / raw)
  To: davem, johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs

Hello,

syzbot hit the following crash on upstream commit
10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +0000)
Merge branch 'perf-urgent-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=230d9e642a85d3fec29c

So far this crash happened 5 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6535492073947136
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6339348970602496
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+230d9e642a85d3fec29c@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 ]------------
add_uevent_var: buffer size too small
WARNING: CPU: 0 PID: 4431 at lib/kobject_uevent.c:594  
add_uevent_var+0x2aa/0x2d0 lib/kobject_uevent.c:594
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 4431 Comm: syzkaller678536 Not tainted 4.16.0-rc7+ #374
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
  panic+0x1e4/0x41c kernel/panic.c:183
  __warn+0x1dc/0x200 kernel/panic.c:547
  report_bug+0x1f4/0x2b0 lib/bug.c:186
  fixup_bug.part.10+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+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:add_uevent_var+0x2aa/0x2d0 lib/kobject_uevent.c:594
RSP: 0018:ffff8801adba6810 EFLAGS: 00010286
RAX: dffffc0000000008 RBX: ffff8801ad7a6d40 RCX: ffffffff815b193e
RDX: 0000000000000000 RSI: 1ffff10035b74cb2 RDI: 1ffff10035b74c87
RBP: ffff8801adba68d8 R08: 1ffff10035b74c49 R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000000 R12: 1ffff10035b74d03
R13: ffff8801ad7a6e58 R14: 00000000000003e6 R15: 0000000000000438
  rfkill_dev_uevent+0x31/0x170 net/rfkill/core.c:813
  dev_uevent+0x2b6/0x7e0 drivers/base/core.c:913
  kobject_uevent_env+0x3fe/0xd30 lib/kobject_uevent.c:476
  kobject_uevent+0x1f/0x30 lib/kobject_uevent.c:565
  device_add+0xd04/0x1650 drivers/base/core.c:1834
  rfkill_register+0x254/0xd60 net/rfkill/core.c:1019
  wiphy_register+0x19d1/0x2050 net/wireless/core.c:872
  ieee80211_register_hw+0x1162/0x3100 net/mac80211/main.c:1041
  mac80211_hwsim_new_radio+0x1d06/0x2fb0  
drivers/net/wireless/mac80211_hwsim.c:2757
  hwsim_new_radio_nl+0x67a/0x8c0 drivers/net/wireless/mac80211_hwsim.c:3214
  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:2447
  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
  netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
  netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1337
  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1900
  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
  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x43fda9
RSP: 002b:00007ffde548edb8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fda9
RDX: 0000000000000000 RSI: 0000000020b3dfc8 RDI: 0000000000000003
RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016d0
R13: 0000000000401760 R14: 0000000000000000 R15: 0000000000000000
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 syzkaller@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.

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

* Re: WARNING in add_uevent_var
  2018-04-02  6:01 WARNING in add_uevent_var syzbot
@ 2018-04-03 12:34 ` Johannes Berg
  2018-05-07 10:13   ` Tetsuo Handa
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2018-04-03 12:34 UTC (permalink / raw)
  To: syzbot, davem, linux-kernel, linux-wireless, netdev, syzkaller-bugs

On Sun, 2018-04-01 at 23:01 -0700, syzbot wrote:

> So far this crash happened 5 times on net-next, upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128
> 

Huh, fun. Looks like you're basically creating a new HWSIM radio with an
insanely long name (4k!) and nothing stops you, until we try to generate
an rfkill instance which sends a uevent and only has a 2k buffer for the
environment variables, where we put the name ...

But yeah, we should probably limit the phy name to something sane, I'll
pick 128 and send a patch.

johannes

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

* Re: WARNING in add_uevent_var
  2018-04-03 12:34 ` Johannes Berg
@ 2018-05-07 10:13   ` Tetsuo Handa
  0 siblings, 0 replies; 3+ messages in thread
From: Tetsuo Handa @ 2018-05-07 10:13 UTC (permalink / raw)
  To: Johannes Berg, syzbot, syzkaller-bugs
  Cc: davem, linux-kernel, linux-wireless, netdev

On 2018/04/03 21:34, Johannes Berg wrote:
> On Sun, 2018-04-01 at 23:01 -0700, syzbot wrote:
> 
>> So far this crash happened 5 times on net-next, upstream.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128
>>
> 
> Huh, fun. Looks like you're basically creating a new HWSIM radio with an
> insanely long name (4k!) and nothing stops you, until we try to generate
> an rfkill instance which sends a uevent and only has a 2k buffer for the
> environment variables, where we put the name ...
> 
> But yeah, we should probably limit the phy name to something sane, I'll
> pick 128 and send a patch.
> 

I think it should be NAME_MAX.

----------------------------------------
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/netlink.h>

int main(int argc, char *argv[])
{
	const int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
	static struct {
		struct nlmsghdr hdr;
		char data[4120 - sizeof(struct nlmsghdr)];
	} buf = { };
	struct sockaddr_nl addr = { .nl_family = AF_NETLINK };
	struct iovec iov = { &buf, sizeof(buf) };
	struct msghdr msg = {
		.msg_name = &addr,
		.msg_namelen = sizeof(addr),
		.msg_iov = &iov,
		.msg_iovlen = 1,
	};
	buf.hdr.nlmsg_len = 0x1018;
	buf.hdr.nlmsg_type = 0x22;
	buf.hdr.nlmsg_flags = 0x109;
	*(uint8_t*) buf.data = 4;
	*(uint8_t*) (buf.data + 1) = 0;
	*(uint16_t*) (buf.data + 2) = 0;
	*(uint16_t*) (buf.data + 4) = 0x1004;
	*(uint16_t*) (buf.data + 6) = 0x11;
	memset(buf.data + 8, 'A', 4096); /* strlen() > NAME_MAX */
	sendmsg(fd, &msg, 0);
	return 0;
}
----------------------------------------



>From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 7 May 2018 15:58:37 +0900
Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc().

syzbot is hitting WARN() at kobject_uevent_env() [1].
This is because the test case is requesting too long name.
Since the name is used as part of pathname under /sys/devices/virtual/ ,
this name parameter must obey the limitations of a filename.
Fix this by applying name validity test to rfkill_alloc().

[1] https://syzkaller.appspot.com/bug?id=c1e1ab1d042b637ee9e25c64b107d51630b9d9ec

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+230d9e642a85d3fec29c@syzkaller.appspotmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
---
 net/rfkill/core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 59d0eb9..d8beebc 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -933,6 +933,10 @@ struct rfkill * __must_check rfkill_alloc(const char *name,
 	if (WARN_ON(type == RFKILL_TYPE_ALL || type >= NUM_RFKILL_TYPES))
 		return NULL;
 
+	if (strlen(name) > NAME_MAX || strchr(name, '/') ||
+	    !strcmp(name, ".") || !strcmp(name, ".."))
+		return NULL;
+
 	rfkill = kzalloc(sizeof(*rfkill) + strlen(name) + 1, GFP_KERNEL);
 	if (!rfkill)
 		return NULL;
-- 
1.8.3.1

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

end of thread, other threads:[~2018-05-07 10:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-02  6:01 WARNING in add_uevent_var syzbot
2018-04-03 12:34 ` Johannes Berg
2018-05-07 10:13   ` Tetsuo Handa

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