On Thu, Mar 10, 2022 at 11:06 AM Tadeusz Struk tadeusz.struk@linaro.org wrote:
On 3/10/22 06:39, Willem de Bruijn wrote:
On Wed, Mar 9, 2022 at 4:37 PM Tadeusz Struk tadeusz.struk@linaro.org wrote:
On 3/8/22 21:01, David Ahern wrote:
On 3/8/22 12:46 PM, Tadeusz Struk wrote:
That fails in the same way:
skbuff: skb_over_panic: text:ffffffff83e7b48b len:65575 put:65575 head:ffff888101f8a000 data:ffff888101f8a088 tail:0x100af end:0x6c0 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:113! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 1852 Comm: repro Not tainted 5.17.0-rc7-00020-gea4424be1688-dirty #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 RIP: 0010:skb_panic+0x173/0x175
I'm not sure how it supposed to help since it doesn't change the alloclen at all.
alloclen is a function of fraglen and fraglen is a function of datalen.
Ok, but in this case it doesn't affect the alloclen and it still fails.
This is some kind of non-standard packet that is being constructed. Do we understand how it is different?
The .syz reproducer is generally a bit more readable than the .c equivalent. Though not as much as an strace of the binary, if you can share that.
r0 = socket$inet6_icmp_raw(0xa, 0x3, 0x3a) connect$inet6(r0, &(0x7f0000000040)={0xa, 0x0, 0x0, @dev, 0x6}, 0x1c) setsockopt$inet6_IPV6_HOPOPTS(r0, 0x29, 0x36, &(0x7f0000000100)=ANY=[@ANYBLOB="52b3"], 0x5a0) sendmmsg$inet(r0, &(0x7f00000002c0)=[{{0x0, 0x0, &(0x7f0000000000)=[{&(0x7f00000000c0)="1d2d", 0xfa5f}], 0x1}}], 0x1, 0xfe80)
Here it is: https://termbin.com/krtr It won't be of much help, I'm afraid, as the offending sendmmsg() call isn't fully printed.
Thanks. It does offer some hints on the other two syscalls:
[pid 644] connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fe80::", &sin6_addr), sin6_scope_id=if_nametoindex("tunl0")}, 28) = 0 [pid 644] setsockopt(3, SOL_IPV6, IPV6_HOPOPTS, "R\263\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1440) = 0
IPV6_HOPOPTS is ns_capable CAP_NET_RAW.
So this adds 1440 bytes to opt_nflen, which is included in fragheaderlen, causing that to be exactly mtu. This means that the payload can never be sent, as each fragment header eats up the entire mtu? This is without any transport headers that would only be part of the first fragment (which go into opt_flen).
If you can maybe catch the error before the skb_put and just return EINVAL, we might see whether sendmmsg is relevant or a simple send would be equivalent. (not super important, that appears unrelated.)