From: Petar Penkov <peterpenko...@gmail.com> Date: Tue, 19 Sep 2017 00:34:00 -0700
> The following patches address this by providing the user(syzkaller) > with the ability to send via napi_gro_receive() and napi_gro_frags(). > Additionally, syzkaller can specify how many fragments there are and > how much data per fragment there is. This is done by exploiting the > convenient structure of iovecs. Finally, this patch series adds > support for exercising the flow dissector during fuzzing. > > The code path including napi_gro_receive() can be enabled via the > CONFIG_TUN_NAPI compile-time flag, and can be used by users other than > syzkaller. The remainder of the changes in this patch series give the > user significantly more control over packets entering the kernel. To > avoid potential security vulnerabilities, hide the ability to send > custom skbs and the flow dissector code paths behind a run-time flag > IFF_NAPI_FRAGS that is advertised and accepted only if CONFIG_TUN_NAPI > is enabled. > > The patch series will be followed with changes to packetdrill, where > these additions to the TUN driver are exercised and demonstrated. > This will give the ability to write regression tests for specific > parts of the early networking stack. > > Patch 1/ Add NAPI struct per receive queue, enable NAPI, and use > napi_gro_receive() > Patch 2/ Use NAPI skb and napi_gro_frags(), exercise flow > dissector, and allow custom skbs. I'm happy with everything except the TUN_NAPI Kconfig knob requirement. Rebuilding something just to test things isn't going to fly very well. Please make it secure somehow, enable this stuff by default. Thanks.
