On Mon, Sep 21, 2020 at 07:56:20AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: eb5f95f1 Merge tag 's390-5.9-6' of git://git.kernel.org/pu.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=13996ad5900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=ffe85b197a57c180 > dashboard link: https://syzkaller.appspot.com/bug?extid=577fbac3145a6eb2e7a5 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+577fbac3145a6eb2e...@syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: stack-out-of-bounds in xfrm_flowi_dport include/net/xfrm.h:877 > [inline] > BUG: KASAN: stack-out-of-bounds in __xfrm6_selector_match > net/xfrm/xfrm_policy.c:216 [inline] > BUG: KASAN: stack-out-of-bounds in xfrm_selector_match+0xf36/0xf60 > net/xfrm/xfrm_policy.c:229 > Read of size 2 at addr ffffc9001914f55c by task syz-executor.4/15633
This is yet another ipv4 mapped ipv6 address with IPsec socket policy combination bug, and I'm sure it is not the last one. We could fix this one by adding another check to match the address family of the policy and the SA selector, but maybe it is better to think about how this should work at all. We can have only one socket policy for each direction and that policy accepts either ipv4 or ipv6. We treat this ipv4 mapped ipv6 address as ipv4 and pass it down the ipv4 stack, so this dual usage will not work with a socket policy. Maybe we can require IPV6_V6ONLY for sockets with policy attached. Thoughts?
