Re: KASAN: use-after-free Read in tomoyo_socket_sendmsg_permission
On Fri, Aug 9, 2019 at 1:53 AM Dmitry Vyukov wrote: > > On Fri, Aug 9, 2019 at 12:08 AM Tetsuo Handa > wrote: > > > > On 2019/08/09 1:45, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:107e47cc vrf: make sure skb->data contains ip header to > > > ma.. > > > git tree: net > > > console output: https://syzkaller.appspot.com/x/log.txt?x=139506d860 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=4dba67bf8b8c9ad7 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=b91501546ab4037f685f > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > This is not TOMOYO's bug. LSM modules expect that "struct sock" does not go > > away. > > > > Also, another use-after-free (presumably on the same "struct sock") was > > concurrently > > inflight at nr_insert_socket() in net/netrom/af_netrom.c . Thus, suspecting > > netrom's bug. > > There is a number of UAFs/refcount bugs in nr sockets lately. Most > likely it's the same issue them. Most of them were bisected to: > > commit c8c8218ec5af5d2598381883acbefbf604e56b5e > Date: Thu Jun 27 21:30:58 2019 + > netrom: fix a memory leak in nr_rx_frame() The UAF introduced by this commit has been fixed. There is another UAF in netrom which exists long before the above commit, it is not fixed. The last time I looked at it, it seems related to the state machine used by netrom sockets, so it is not easy. Thanks,
Re: Reminder: 13 open syzbot bugs in "net/netrom" subsystem
On Tue, Jul 23, 2019 at 6:47 PM Eric Biggers wrote: > > [This email was generated by a script. Let me know if you have any > suggestions > to make it better, or if you want it re-generated with the latest status.] > > Of the currently open syzbot reports against the upstream kernel, I've > manually > marked 13 of them as possibly being bugs in the "net/netrom" subsystem. I've > listed these reports below, sorted by an algorithm that tries to list first > the > reports most likely to be still valid, important, and actionable. > > Of these 13 bugs, 8 were seen in mainline in the last week. > > Of these 13 bugs, 4 were bisected to commits from the following person: > > Cong Wang These 4 should be fixed by this pending patch: http://patchwork.ozlabs.org/patch/1135398/ Thanks.
Re: KASAN: use-after-free Read in nr_insert_socket
On Thu, Jul 18, 2019 at 5:18 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a5b64700 fix: taprio: Change type of txtime-delay paramete..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1588b45860
> kernel config: https://syzkaller.appspot.com/x/.config?x=87305c3ca9c25c70
> dashboard link: https://syzkaller.appspot.com/bug?extid=9399c158fcc09b21d0d2
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=105a61a460
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153ef94860
>
> The bug was bisected to:
>
> commit c8c8218ec5af5d2598381883acbefbf604e56b5e
> Author: Cong Wang
> Date: Thu Jun 27 21:30:58 2019 +
>
> netrom: fix a memory leak in nr_rx_frame()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=159ef94860
> final crash:https://syzkaller.appspot.com/x/report.txt?x=179ef94860
> console output: https://syzkaller.appspot.com/x/log.txt?x=139ef94860
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9399c158fcc09b21d...@syzkaller.appspotmail.com
> Fixes: c8c8218ec5af ("netrom: fix a memory leak in nr_rx_frame()")
>
> ==
> BUG: KASAN: use-after-free in atomic_read
> /./include/asm-generic/atomic-instrumented.h:26 [inline]
> BUG: KASAN: use-after-free in refcount_inc_not_zero_checked+0x81/0x200
> /lib/refcount.c:123
> Read of size 4 at addr 8880a5d3f380 by task swapper/1/0
>
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.2.0+ #89
> 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+0x172/0x1f0 /lib/dump_stack.c:113
> print_address_description.cold+0xd4/0x306 /mm/kasan/report.c:351
> __kasan_report.cold+0x1b/0x36 /mm/kasan/report.c:482
> kasan_report+0x12/0x20 /mm/kasan/common.c:612
> check_memory_region_inline /mm/kasan/generic.c:185 [inline]
> check_memory_region+0x134/0x1a0 /mm/kasan/generic.c:192
> __kasan_check_read+0x11/0x20 /mm/kasan/common.c:92
> atomic_read /./include/asm-generic/atomic-instrumented.h:26 [inline]
> refcount_inc_not_zero_checked+0x81/0x200 /lib/refcount.c:123
> refcount_inc_checked+0x17/0x70 /lib/refcount.c:156
> sock_hold /./include/net/sock.h:649 [inline]
> sk_add_node /./include/net/sock.h:701 [inline]
> nr_insert_socket+0x2d/0xe0 /net/netrom/af_netrom.c:137
Looks like nr_insert_socket() doesn't hold a refcnt before inserting
it into a global list.
Let me think about how to fix this.
Thanks.
Re: KASAN: use-after-free Read in selinux_netlbl_socket_setsockopt
On Thu, Jan 31, 2019 at 10:56 PM Dmitry Vyukov wrote: > Hi Paul, > > Searching for af_netrom across other syzbot bugs: > https://groups.google.com/forum/#!searchin/syzkaller-bugs/af_netrom%7Csort:date > > I see at least: > https://syzkaller.appspot.com/bug?extid=b0b1952f5864b4009b09 > https://syzkaller.appspot.com/bug?extid=febf3c50d4262e578b1c > https://syzkaller.appspot.com/bug?extid=defa700d16f1bd1b9a05 > > Which suggests there are some serious lifetime problems in netrom > sockets. That would probably explain this crash as well. This is supposed to be fixed by: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=63346650c1a94a92be61a57416ac88c0a47c4327 Please let me know if it isn't. Thanks.
[Patch net] netrom: switch to sock timer API
sk_reset_timer() and sk_stop_timer() properly handle
sock refcnt for timer function. Switching to them
could fix a refcounting bug reported by syzbot.
Reported-and-tested-by: syzbot+defa700d16f1bd1b9...@syzkaller.appspotmail.com
Cc: Ralf Baechle
Cc: linux-hams@vger.kernel.org
Signed-off-by: Cong Wang
---
net/netrom/nr_timer.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/netrom/nr_timer.c b/net/netrom/nr_timer.c
index cbd51ed5a2d7..908e53ab47a4 100644
--- a/net/netrom/nr_timer.c
+++ b/net/netrom/nr_timer.c
@@ -52,21 +52,21 @@ void nr_start_t1timer(struct sock *sk)
{
struct nr_sock *nr = nr_sk(sk);
- mod_timer(&nr->t1timer, jiffies + nr->t1);
+ sk_reset_timer(sk, &nr->t1timer, jiffies + nr->t1);
}
void nr_start_t2timer(struct sock *sk)
{
struct nr_sock *nr = nr_sk(sk);
- mod_timer(&nr->t2timer, jiffies + nr->t2);
+ sk_reset_timer(sk, &nr->t2timer, jiffies + nr->t2);
}
void nr_start_t4timer(struct sock *sk)
{
struct nr_sock *nr = nr_sk(sk);
- mod_timer(&nr->t4timer, jiffies + nr->t4);
+ sk_reset_timer(sk, &nr->t4timer, jiffies + nr->t4);
}
void nr_start_idletimer(struct sock *sk)
@@ -74,37 +74,37 @@ void nr_start_idletimer(struct sock *sk)
struct nr_sock *nr = nr_sk(sk);
if (nr->idle > 0)
- mod_timer(&nr->idletimer, jiffies + nr->idle);
+ sk_reset_timer(sk, &nr->idletimer, jiffies + nr->idle);
}
void nr_start_heartbeat(struct sock *sk)
{
- mod_timer(&sk->sk_timer, jiffies + 5 * HZ);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + 5 * HZ);
}
void nr_stop_t1timer(struct sock *sk)
{
- del_timer(&nr_sk(sk)->t1timer);
+ sk_stop_timer(sk, &nr_sk(sk)->t1timer);
}
void nr_stop_t2timer(struct sock *sk)
{
- del_timer(&nr_sk(sk)->t2timer);
+ sk_stop_timer(sk, &nr_sk(sk)->t2timer);
}
void nr_stop_t4timer(struct sock *sk)
{
- del_timer(&nr_sk(sk)->t4timer);
+ sk_stop_timer(sk, &nr_sk(sk)->t4timer);
}
void nr_stop_idletimer(struct sock *sk)
{
- del_timer(&nr_sk(sk)->idletimer);
+ sk_stop_timer(sk, &nr_sk(sk)->idletimer);
}
void nr_stop_heartbeat(struct sock *sk)
{
- del_timer(&sk->sk_timer);
+ sk_stop_timer(sk, &sk->sk_timer);
}
int nr_t1timer_running(struct sock *sk)
--
2.20.1
Re: possible deadlock in nr_destroy_socket
syzbot confirmed the latest net tree is fine, so: #syz fix: netrom: fix locking in nr_find_socket()
Re: KASAN: use-after-free Read in nr_rx_frame
#syz fix: netrom: fix locking in nr_find_socket()
Re: WARNING: locking bug in nr_release
On Mon, Jan 7, 2019 at 1:52 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:574823bfab82 Change mincore() to count "mapped" pages rath.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=121dc980c0 > kernel config: https://syzkaller.appspot.com/x/.config?x=d7b516c45456 > dashboard link: https://syzkaller.appspot.com/bug?extid=23f5ac6e7c0b6cc63734 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+23f5ac6e7c0b6cc63...@syzkaller.appspotmail.com > > [ cut here ] > DEBUG_LOCKS_WARN_ON(class_idx > MAX_LOCKDEP_KEYS) > WARNING: CPU: 1 PID: 30980 at kernel/locking/lockdep.c:3315 > __lock_acquire+0x14cd/0x4a30 kernel/locking/lockdep.c:3315 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 1 PID: 30980 Comm: syz-executor5 Not tainted 4.20.0+ #13 > 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+0x1db/0x2d0 lib/dump_stack.c:113 > panic+0x2cb/0x65c kernel/panic.c:214 > __warn.cold+0x20/0x48 kernel/panic.c:571 > report_bug+0x263/0x2b0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:178 [inline] > fixup_bug arch/x86/kernel/traps.c:173 [inline] > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 > RIP: 0010:__lock_acquire+0x14cd/0x4a30 kernel/locking/lockdep.c:3315 > Code: 8b 1d 3b eb f7 08 45 85 db 0f 85 f0 f3 ff ff 48 c7 c6 60 a1 4b 88 48 > c7 c7 80 76 4b 88 44 89 9c 24 98 00 00 00 e8 f3 5f e7 ff <0f> 0b 44 8b 9c > 24 98 00 00 00 e9 c9 f3 ff ff 8b 0d 2e 9c f2 09 85 > RSP: 0018:8880710cf0c0 EFLAGS: 00010086 > RAX: RBX: fffe4386 RCX: > RDX: RSI: 81684ce6 RDI: 0006 > RBP: 8880710cf350 R08: 888081d582c0 R09: fbfff1333299 > R10: fbfff1333298 R11: 84c3 R12: 888081d582c0 > R13: 888081d58b8a R14: 0001 R15: fffe4386 > kobject: 'kvm' (d564ee4d): kobject_uevent_env > lock_acquire+0x1db/0x570 kernel/locking/lockdep.c:3841 > kobject: 'kvm' (d564ee4d): fill_kobj_path: path > = '/devices/virtual/misc/kvm' > __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline] > _raw_write_lock_bh+0x33/0x50 kernel/locking/spinlock.c:312 > sock_orphan include/net/sock.h:1796 [inline] This is probably a consequence of the use-after-free bug, so: #syz dup: WARNING: refcount bug in nr_release
Re: KASAN: use-after-free Read in ax25_fillin_cb
Hi, Joerg On Sat, Dec 29, 2018 at 2:06 PM Joerg Reuter wrote: > Unfortunately, I'm on a low bandwidth connection right now. I'd be > grateful if someone could create a patch. This is likely not a high > impact issue (unpriviliged users can't set up or tear down interfaces), > still it may cause hard to find memory corruptions. I already sent a patch: http://patchwork.ozlabs.org/patch/1019386/ Sorry for forgetting to Cc more people. Thanks.
