netdev - Re: [PATCH net] fib: fib_dump_info can no longer use __in_dev_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 03 Nov 2017 14:28:08 +0900 (KST)
From:   David Miller <davem@...emloft.net>
To:     fw@...len.de
Cc:     netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        bot+e52a2ae091b628f72765583c9faedc961c83b7e7@...kaller.appspotmail.com
Subject: Re: [PATCH net] fib: fib_dump_info can no longer use
 __in_dev_get_rtnl

From: Florian Westphal <fw@...len.de>
Date: Thu,  2 Nov 2017 16:02:20 +0100

> syzbot reported yet another regression added with DOIT_UNLOCKED.
> When nexthop is marked as dead, fib_dump_info uses __in_dev_get_rtnl():
> 
> ./include/linux/inetdevice.h:230 suspicious rcu_dereference_protected() usage!
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by syz-executor2/23859:
>  #0:  (rcu_read_lock){....}, at: [<ffffffff840283f0>]
> inet_rtm_getroute+0xaa0/0x2d70 net/ipv4/route.c:2738
> [..]
>   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
> ..
> 
> This isn't safe anymore, callers either hold RTNL mutex or rcu read lock,
> so these spots must use rcu_dereference_rtnl() or plain rcu_derefence()
> (plus unconditional rcu read lock).
> 
> This does the latter.
> 
> Fixes: 394f51abb3d04f ("ipv4: route: set ipv4 RTM_GETROUTE to not use rtnl")
> Reported-by: syzbot <syzkaller@...glegroups.com>
> Signed-off-by: Florian Westphal <fw@...len.de>

Applied, thanks Florian.