KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
while __ip_make_skb() is running, the function will access icmphdr in the
skb even if it is not included. This causes the issue reported by KMSAN.
Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
on the socket.
[1]
BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
__ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
ip_finish_skb include/net/ip.h:243 [inline]
ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x274/0x3c0 net/socket.c:745
__sys_sendto+0x62c/0x7b0 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x130/0x200 net/socket.c:2199
do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3804 [inline]
slab_alloc_node mm/slub.c:3845 [inline]
kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
__alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
alloc_skb include/linux/skbuff.h:1318 [inline]
__ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x274/0x3c0 net/socket.c:745
__sys_sendto+0x62c/0x7b0 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x130/0x200 net/socket.c:2199
do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
Reported-by: syzkaller <[email protected]>
Signed-off-by: Shigeru Yoshida <[email protected]>
---
I think IPv6 has a similar issue. If this patch is accepted, I will send
a patch for IPv6.
---
net/ipv4/ip_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 1fe794967211..39229fd0601a 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
* by icmp_hdr(skb)->type.
*/
if (sk->sk_type == SOCK_RAW &&
- !inet_test_bit(HDRINCL, sk))
+ !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
icmp_type = fl4->fl4_icmp_type;
else
icmp_type = icmp_hdr(skb)->type;
--
2.44.0
On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
>
> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
> while __ip_make_skb() is running, the function will access icmphdr in the
> skb even if it is not included. This causes the issue reported by KMSAN.
>
> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
> on the socket.
>
> [1]
What is the kernel version for this trace ?
> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> ip_finish_skb include/net/ip.h:243 [inline]
> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> sock_sendmsg_nosec net/socket.c:730 [inline]
> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> __do_sys_sendto net/socket.c:2203 [inline]
> __se_sys_sendto net/socket.c:2199 [inline]
> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>
> Uninit was created at:
> slab_post_alloc_hook mm/slub.c:3804 [inline]
> slab_alloc_node mm/slub.c:3845 [inline]
> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
> alloc_skb include/linux/skbuff.h:1318 [inline]
> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> sock_sendmsg_nosec net/socket.c:730 [inline]
> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> __do_sys_sendto net/socket.c:2203 [inline]
> __se_sys_sendto net/socket.c:2199 [inline]
> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>
> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
> Reported-by: syzkaller <[email protected]>
> Signed-off-by: Shigeru Yoshida <[email protected]>
> ---
> I think IPv6 has a similar issue. If this patch is accepted, I will send
> a patch for IPv6.
> ---
> net/ipv4/ip_output.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 1fe794967211..39229fd0601a 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
> * by icmp_hdr(skb)->type.
> */
> if (sk->sk_type == SOCK_RAW &&
> - !inet_test_bit(HDRINCL, sk))
> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
> icmp_type = fl4->fl4_icmp_type;
> else
> icmp_type = icmp_hdr(skb)->type;
> --
> 2.44.0
>
Thanks for your patch.
I do not think this is enough, as far as syzkaller is concerned.
raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
On Mon, Mar 25, 2024 at 10:38 AM Shigeru Yoshida <[email protected]> wrote:
>
> On Mon, 25 Mar 2024 10:01:25 +0100, Eric Dumazet wrote:
> > On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
> >>
> >> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
> >> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
> >> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
> >> while __ip_make_skb() is running, the function will access icmphdr in the
> >> skb even if it is not included. This causes the issue reported by KMSAN.
> >>
> >> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
> >> on the socket.
> >>
> >> [1]
> >
> > What is the kernel version for this trace ?
>
> Sorry, I used the following version:
>
> CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
>
> >> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> >> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> >> ip_finish_skb include/net/ip.h:243 [inline]
> >> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
> >> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> >> sock_sendmsg_nosec net/socket.c:730 [inline]
> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> >> __do_sys_sendto net/socket.c:2203 [inline]
> >> __se_sys_sendto net/socket.c:2199 [inline]
> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
> >>
> >> Uninit was created at:
> >> slab_post_alloc_hook mm/slub.c:3804 [inline]
> >> slab_alloc_node mm/slub.c:3845 [inline]
> >> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
> >> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
> >> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
> >> alloc_skb include/linux/skbuff.h:1318 [inline]
> >> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
> >> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
> >> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> >> sock_sendmsg_nosec net/socket.c:730 [inline]
> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> >> __do_sys_sendto net/socket.c:2203 [inline]
> >> __se_sys_sendto net/socket.c:2199 [inline]
> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
> >>
> >> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
> >> Reported-by: syzkaller <[email protected]>
> >> Signed-off-by: Shigeru Yoshida <[email protected]>
> >> ---
> >> I think IPv6 has a similar issue. If this patch is accepted, I will send
> >> a patch for IPv6.
> >> ---
> >> net/ipv4/ip_output.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> >> index 1fe794967211..39229fd0601a 100644
> >> --- a/net/ipv4/ip_output.c
> >> +++ b/net/ipv4/ip_output.c
> >> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
> >> * by icmp_hdr(skb)->type.
> >> */
> >> if (sk->sk_type == SOCK_RAW &&
> >> - !inet_test_bit(HDRINCL, sk))
> >> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
> >> icmp_type = fl4->fl4_icmp_type;
> >> else
> >> icmp_type = icmp_hdr(skb)->type;
> >> --
> >> 2.44.0
> >>
> >
> > Thanks for your patch.
> >
> > I do not think this is enough, as far as syzkaller is concerned.
> >
> > raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
>
> Thank you for your comment. But I don't understand it clearly. What
> exactly do you mean by "garbage"?
>
> raw_probe_proto_opt() immediately returns 0 if fl4->flowi4_proto is
> not IPPROTO_ICMP:
>
> static int raw_probe_proto_opt(struct raw_frag_vec *rfv, struct flowi4 *fl4)
> {
> int err;
>
> if (fl4->flowi4_proto != IPPROTO_ICMP)
> return 0;
>
> In this case, the function doesn't set fl4_icmp_type. Do you mean this
> case?
There are multiple ways to return early from this function.
In all of them, fl4->fl4_icmp_type is left uninitialized, so syzbot
will find ways to trigger a related bug,
if you assume later that fl4->fl4_icmp_type contains valid (initialized) data.
On Mon, 25 Mar 2024 10:01:25 +0100, Eric Dumazet wrote:
> On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
>>
>> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
>> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
>> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
>> while __ip_make_skb() is running, the function will access icmphdr in the
>> skb even if it is not included. This causes the issue reported by KMSAN.
>>
>> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
>> on the socket.
>>
>> [1]
>
> What is the kernel version for this trace ?
Sorry, I used the following version:
CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
>> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> ip_finish_skb include/net/ip.h:243 [inline]
>> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
>> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
>> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> sock_sendmsg_nosec net/socket.c:730 [inline]
>> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> __do_sys_sendto net/socket.c:2203 [inline]
>> __se_sys_sendto net/socket.c:2199 [inline]
>> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>>
>> Uninit was created at:
>> slab_post_alloc_hook mm/slub.c:3804 [inline]
>> slab_alloc_node mm/slub.c:3845 [inline]
>> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
>> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
>> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
>> alloc_skb include/linux/skbuff.h:1318 [inline]
>> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
>> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
>> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
>> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> sock_sendmsg_nosec net/socket.c:730 [inline]
>> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> __do_sys_sendto net/socket.c:2203 [inline]
>> __se_sys_sendto net/socket.c:2199 [inline]
>> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>>
>> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
>> Reported-by: syzkaller <[email protected]>
>> Signed-off-by: Shigeru Yoshida <[email protected]>
>> ---
>> I think IPv6 has a similar issue. If this patch is accepted, I will send
>> a patch for IPv6.
>> ---
>> net/ipv4/ip_output.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> index 1fe794967211..39229fd0601a 100644
>> --- a/net/ipv4/ip_output.c
>> +++ b/net/ipv4/ip_output.c
>> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
>> * by icmp_hdr(skb)->type.
>> */
>> if (sk->sk_type == SOCK_RAW &&
>> - !inet_test_bit(HDRINCL, sk))
>> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
>> icmp_type = fl4->fl4_icmp_type;
>> else
>> icmp_type = icmp_hdr(skb)->type;
>> --
>> 2.44.0
>>
>
> Thanks for your patch.
>
> I do not think this is enough, as far as syzkaller is concerned.
>
> raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
Thank you for your comment. But I don't understand it clearly. What
exactly do you mean by "garbage"?
raw_probe_proto_opt() immediately returns 0 if fl4->flowi4_proto is
not IPPROTO_ICMP:
static int raw_probe_proto_opt(struct raw_frag_vec *rfv, struct flowi4 *fl4)
{
int err;
if (fl4->flowi4_proto != IPPROTO_ICMP)
return 0;
In this case, the function doesn't set fl4_icmp_type. Do you mean this
case?
Thanks,
Shigeru
On Mon, 25 Mar 2024 11:05:33 +0100, Eric Dumazet wrote:
> On Mon, Mar 25, 2024 at 10:38 AM Shigeru Yoshida <[email protected]> wrote:
>>
>> On Mon, 25 Mar 2024 10:01:25 +0100, Eric Dumazet wrote:
>> > On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
>> >>
>> >> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
>> >> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
>> >> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
>> >> while __ip_make_skb() is running, the function will access icmphdr in the
>> >> skb even if it is not included. This causes the issue reported by KMSAN.
>> >>
>> >> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
>> >> on the socket.
>> >>
>> >> [1]
>> >
>> > What is the kernel version for this trace ?
>>
>> Sorry, I used the following version:
>>
>> CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
>>
>> >> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> >> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> >> ip_finish_skb include/net/ip.h:243 [inline]
>> >> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
>> >> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
>> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> >> sock_sendmsg_nosec net/socket.c:730 [inline]
>> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> >> __do_sys_sendto net/socket.c:2203 [inline]
>> >> __se_sys_sendto net/socket.c:2199 [inline]
>> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>> >>
>> >> Uninit was created at:
>> >> slab_post_alloc_hook mm/slub.c:3804 [inline]
>> >> slab_alloc_node mm/slub.c:3845 [inline]
>> >> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
>> >> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
>> >> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
>> >> alloc_skb include/linux/skbuff.h:1318 [inline]
>> >> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
>> >> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
>> >> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
>> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> >> sock_sendmsg_nosec net/socket.c:730 [inline]
>> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> >> __do_sys_sendto net/socket.c:2203 [inline]
>> >> __se_sys_sendto net/socket.c:2199 [inline]
>> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>> >>
>> >> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
>> >> Reported-by: syzkaller <[email protected]>
>> >> Signed-off-by: Shigeru Yoshida <[email protected]>
>> >> ---
>> >> I think IPv6 has a similar issue. If this patch is accepted, I will send
>> >> a patch for IPv6.
>> >> ---
>> >> net/ipv4/ip_output.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> >> index 1fe794967211..39229fd0601a 100644
>> >> --- a/net/ipv4/ip_output.c
>> >> +++ b/net/ipv4/ip_output.c
>> >> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
>> >> * by icmp_hdr(skb)->type.
>> >> */
>> >> if (sk->sk_type == SOCK_RAW &&
>> >> - !inet_test_bit(HDRINCL, sk))
>> >> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
>> >> icmp_type = fl4->fl4_icmp_type;
>> >> else
>> >> icmp_type = icmp_hdr(skb)->type;
>> >> --
>> >> 2.44.0
>> >>
>> >
>> > Thanks for your patch.
>> >
>> > I do not think this is enough, as far as syzkaller is concerned.
>> >
>> > raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
>>
>> Thank you for your comment. But I don't understand it clearly. What
>> exactly do you mean by "garbage"?
>>
>> raw_probe_proto_opt() immediately returns 0 if fl4->flowi4_proto is
>> not IPPROTO_ICMP:
>>
>> static int raw_probe_proto_opt(struct raw_frag_vec *rfv, struct flowi4 *fl4)
>> {
>> int err;
>>
>> if (fl4->flowi4_proto != IPPROTO_ICMP)
>> return 0;
>>
>> In this case, the function doesn't set fl4_icmp_type. Do you mean this
>> case?
>
> There are multiple ways to return early from this function.
>
> In all of them, fl4->fl4_icmp_type is left uninitialized, so syzbot
> will find ways to trigger a related bug,
> if you assume later that fl4->fl4_icmp_type contains valid (initialized) data.
Thank you for your reply. I see your point.
fl4->fl4_icmp_type is part of flowi_uli union in flowi4 structure, and
flowi4_init_output() initializes fl4_dport and fl4_sport to zero.
I thought this also initializes fl4_icmp_type and fl4_icmp_code. Do
you think we should initialize fl4_icmp_type and fl4_icmp_code
explicitly, otherwise am I misunderstanding?
Thanks,
Shigeru
On Mon, Mar 25, 2024 at 6:46 PM Shigeru Yoshida <[email protected]> wrote:
>
> On Mon, 25 Mar 2024 11:05:33 +0100, Eric Dumazet wrote:
> > On Mon, Mar 25, 2024 at 10:38 AM Shigeru Yoshida <[email protected]> wrote:
> >>
> >> On Mon, 25 Mar 2024 10:01:25 +0100, Eric Dumazet wrote:
> >> > On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
> >> >>
> >> >> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
> >> >> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
> >> >> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
> >> >> while __ip_make_skb() is running, the function will access icmphdr in the
> >> >> skb even if it is not included. This causes the issue reported by KMSAN.
> >> >>
> >> >> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
> >> >> on the socket.
> >> >>
> >> >> [1]
> >> >
> >> > What is the kernel version for this trace ?
> >>
> >> Sorry, I used the following version:
> >>
> >> CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
> >>
> >> >> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> >> >> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
> >> >> ip_finish_skb include/net/ip.h:243 [inline]
> >> >> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
> >> >> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
> >> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> >> >> sock_sendmsg_nosec net/socket.c:730 [inline]
> >> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> >> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> >> >> __do_sys_sendto net/socket.c:2203 [inline]
> >> >> __se_sys_sendto net/socket.c:2199 [inline]
> >> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> >> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> >> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
> >> >>
> >> >> Uninit was created at:
> >> >> slab_post_alloc_hook mm/slub.c:3804 [inline]
> >> >> slab_alloc_node mm/slub.c:3845 [inline]
> >> >> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
> >> >> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
> >> >> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
> >> >> alloc_skb include/linux/skbuff.h:1318 [inline]
> >> >> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
> >> >> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
> >> >> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
> >> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
> >> >> sock_sendmsg_nosec net/socket.c:730 [inline]
> >> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
> >> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
> >> >> __do_sys_sendto net/socket.c:2203 [inline]
> >> >> __se_sys_sendto net/socket.c:2199 [inline]
> >> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
> >> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
> >> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
> >> >>
> >> >> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
> >> >> Reported-by: syzkaller <[email protected]>
> >> >> Signed-off-by: Shigeru Yoshida <[email protected]>
> >> >> ---
> >> >> I think IPv6 has a similar issue. If this patch is accepted, I will send
> >> >> a patch for IPv6.
> >> >> ---
> >> >> net/ipv4/ip_output.c | 2 +-
> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> >> >> index 1fe794967211..39229fd0601a 100644
> >> >> --- a/net/ipv4/ip_output.c
> >> >> +++ b/net/ipv4/ip_output.c
> >> >> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
> >> >> * by icmp_hdr(skb)->type.
> >> >> */
> >> >> if (sk->sk_type == SOCK_RAW &&
> >> >> - !inet_test_bit(HDRINCL, sk))
> >> >> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
> >> >> icmp_type = fl4->fl4_icmp_type;
> >> >> else
> >> >> icmp_type = icmp_hdr(skb)->type;
> >> >> --
> >> >> 2.44.0
> >> >>
> >> >
> >> > Thanks for your patch.
> >> >
> >> > I do not think this is enough, as far as syzkaller is concerned.
> >> >
> >> > raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
> >>
> >> Thank you for your comment. But I don't understand it clearly. What
> >> exactly do you mean by "garbage"?
> >>
> >> raw_probe_proto_opt() immediately returns 0 if fl4->flowi4_proto is
> >> not IPPROTO_ICMP:
> >>
> >> static int raw_probe_proto_opt(struct raw_frag_vec *rfv, struct flowi4 *fl4)
> >> {
> >> int err;
> >>
> >> if (fl4->flowi4_proto != IPPROTO_ICMP)
> >> return 0;
> >>
> >> In this case, the function doesn't set fl4_icmp_type. Do you mean this
> >> case?
> >
> > There are multiple ways to return early from this function.
> >
> > In all of them, fl4->fl4_icmp_type is left uninitialized, so syzbot
> > will find ways to trigger a related bug,
> > if you assume later that fl4->fl4_icmp_type contains valid (initialized) data.
>
> Thank you for your reply. I see your point.
>
> fl4->fl4_icmp_type is part of flowi_uli union in flowi4 structure, and
> flowi4_init_output() initializes fl4_dport and fl4_sport to zero.
>
> I thought this also initializes fl4_icmp_type and fl4_icmp_code. Do
> you think we should initialize fl4_icmp_type and fl4_icmp_code
> explicitly, otherwise am I misunderstanding?
Yes, I am precisely saying this : do not rely on some union layout,
without mentioning it in the changelog
or even better in a comment.
If you want to avoid clearing these fields, please add a
BUILD_BUG_ON() to make sure
a unrelated future change in include/net/flow.h does not break a
hidden assumption.
(ie : clearing fl4_dport and fl4_sport also clears fl4_icmp_type and
fl4_icmp_code.)
On Mon, 25 Mar 2024 20:56:43 +0100, Eric Dumazet wrote:
> On Mon, Mar 25, 2024 at 6:46 PM Shigeru Yoshida <[email protected]> wrote:
>>
>> On Mon, 25 Mar 2024 11:05:33 +0100, Eric Dumazet wrote:
>> > On Mon, Mar 25, 2024 at 10:38 AM Shigeru Yoshida <[email protected]> wrote:
>> >>
>> >> On Mon, 25 Mar 2024 10:01:25 +0100, Eric Dumazet wrote:
>> >> > On Sun, Mar 24, 2024 at 6:06 AM Shigeru Yoshida <[email protected]> wrote:
>> >> >>
>> >> >> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()
>> >> >> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
>> >> >> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
>> >> >> while __ip_make_skb() is running, the function will access icmphdr in the
>> >> >> skb even if it is not included. This causes the issue reported by KMSAN.
>> >> >>
>> >> >> Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL
>> >> >> on the socket.
>> >> >>
>> >> >> [1]
>> >> >
>> >> > What is the kernel version for this trace ?
>> >>
>> >> Sorry, I used the following version:
>> >>
>> >> CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
>> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
>> >>
>> >> >> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> >> >> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
>> >> >> ip_finish_skb include/net/ip.h:243 [inline]
>> >> >> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
>> >> >> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
>> >> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> >> >> sock_sendmsg_nosec net/socket.c:730 [inline]
>> >> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> >> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> >> >> __do_sys_sendto net/socket.c:2203 [inline]
>> >> >> __se_sys_sendto net/socket.c:2199 [inline]
>> >> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> >> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> >> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>> >> >>
>> >> >> Uninit was created at:
>> >> >> slab_post_alloc_hook mm/slub.c:3804 [inline]
>> >> >> slab_alloc_node mm/slub.c:3845 [inline]
>> >> >> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
>> >> >> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
>> >> >> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
>> >> >> alloc_skb include/linux/skbuff.h:1318 [inline]
>> >> >> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
>> >> >> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
>> >> >> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
>> >> >> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
>> >> >> sock_sendmsg_nosec net/socket.c:730 [inline]
>> >> >> __sock_sendmsg+0x274/0x3c0 net/socket.c:745
>> >> >> __sys_sendto+0x62c/0x7b0 net/socket.c:2191
>> >> >> __do_sys_sendto net/socket.c:2203 [inline]
>> >> >> __se_sys_sendto net/socket.c:2199 [inline]
>> >> >> __x64_sys_sendto+0x130/0x200 net/socket.c:2199
>> >> >> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
>> >> >> entry_SYSCALL_64_after_hwframe+0x6d/0x75
>> >> >>
>> >> >> Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()")
>> >> >> Reported-by: syzkaller <[email protected]>
>> >> >> Signed-off-by: Shigeru Yoshida <[email protected]>
>> >> >> ---
>> >> >> I think IPv6 has a similar issue. If this patch is accepted, I will send
>> >> >> a patch for IPv6.
>> >> >> ---
>> >> >> net/ipv4/ip_output.c | 2 +-
>> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> >> >> index 1fe794967211..39229fd0601a 100644
>> >> >> --- a/net/ipv4/ip_output.c
>> >> >> +++ b/net/ipv4/ip_output.c
>> >> >> @@ -1473,7 +1473,7 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
>> >> >> * by icmp_hdr(skb)->type.
>> >> >> */
>> >> >> if (sk->sk_type == SOCK_RAW &&
>> >> >> - !inet_test_bit(HDRINCL, sk))
>> >> >> + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH))
>> >> >> icmp_type = fl4->fl4_icmp_type;
>> >> >> else
>> >> >> icmp_type = icmp_hdr(skb)->type;
>> >> >> --
>> >> >> 2.44.0
>> >> >>
>> >> >
>> >> > Thanks for your patch.
>> >> >
>> >> > I do not think this is enough, as far as syzkaller is concerned.
>> >> >
>> >> > raw_probe_proto_opt() can leave garbage in fl4_icmp_type (and fl4_icmp_code)
>> >>
>> >> Thank you for your comment. But I don't understand it clearly. What
>> >> exactly do you mean by "garbage"?
>> >>
>> >> raw_probe_proto_opt() immediately returns 0 if fl4->flowi4_proto is
>> >> not IPPROTO_ICMP:
>> >>
>> >> static int raw_probe_proto_opt(struct raw_frag_vec *rfv, struct flowi4 *fl4)
>> >> {
>> >> int err;
>> >>
>> >> if (fl4->flowi4_proto != IPPROTO_ICMP)
>> >> return 0;
>> >>
>> >> In this case, the function doesn't set fl4_icmp_type. Do you mean this
>> >> case?
>> >
>> > There are multiple ways to return early from this function.
>> >
>> > In all of them, fl4->fl4_icmp_type is left uninitialized, so syzbot
>> > will find ways to trigger a related bug,
>> > if you assume later that fl4->fl4_icmp_type contains valid (initialized) data.
>>
>> Thank you for your reply. I see your point.
>>
>> fl4->fl4_icmp_type is part of flowi_uli union in flowi4 structure, and
>> flowi4_init_output() initializes fl4_dport and fl4_sport to zero.
>>
>> I thought this also initializes fl4_icmp_type and fl4_icmp_code. Do
>> you think we should initialize fl4_icmp_type and fl4_icmp_code
>> explicitly, otherwise am I misunderstanding?
>
> Yes, I am precisely saying this : do not rely on some union layout,
> without mentioning it in the changelog
> or even better in a comment.
>
> If you want to avoid clearing these fields, please add a
> BUILD_BUG_ON() to make sure
> a unrelated future change in include/net/flow.h does not break a
> hidden assumption.
>
> (ie : clearing fl4_dport and fl4_sport also clears fl4_icmp_type and
> fl4_icmp_code.)
Sorry for the late response.
Thank you Eric! I got it. I will try to make v2 patch this weekend.
Thanks,
Shigeru