> From: Lorenzo Bianconi <lorenzo.bianc...@redhat.com> > Date: Fri, 2 Mar 2018 11:53:06 +0100 > >> Fix the following slab-out-of-bounds kasan report in >> ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not >> linear and the accessed data are not in the linear data region of orig_skb > ... >> Reported-by: Jianlin Shi <ji...@redhat.com> >> Reviewed-by: Stefano Brivio <sbri...@redhat.com> >> Signed-off-by: Lorenzo Bianconi <lorenzo.bianc...@redhat.com> > > As a bug fix this should be targetting 'net' not 'net-next'. > > Furthermore, we need an appropriate Fixes: tag so we know when this > problem existed. > > If you go far back and it seems like the problem has always been > there, say so and mention how far back you checked.
Hi Dave, Yes sorry, that is exactly the case. Bisecting the issue, I am able to trigger the kasan report on 4.14 and I have not gone back further. Moreover the issue is much more hard to trigger on net-next (or net) respect to 4.14. > > It also helps to explain exactly how the condition is created > ("X creates packet with Y bytes of header space, Z fragments > it at byte N, and that's how we end up here with such a packet") > because such a description aids understanding and might help > suggest alternative (less expensive, cleaner) ways to fix the > problem. > > Thanks. The test scenario consists of 4 devices (simulated using veth and namespaces): - H0: data sender, connected to LAN0 - H1: data receiver, connected to LAN1 - GW0 and GW1: routers between LAN0 and LAN1. Both of them have an ethernet connection on LAN{0,1} - The default route on H{0,1} is GW0 - using ip command on GW0, set GW1 as next hop for LAN1 from LAN0 - create a ip6ip6 tunnel between H0 and H1 - send 3 concurrent data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (buffer size is set to 16K) - while data streams are active flush the route cache on HA multiple times. Regards, Lorenzo