netdev - Re: [PATCH net 2/3] inet: null check for close in inet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKvKAq=tN029infHi2MtQ7GzdedHKB0arfYe3cBawqZLg@mail.gmail.com>
Date: Mon, 24 Jun 2024 15:42:12 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Geliang Tang <geliang@...nel.org>
Cc: John Fastabend <john.fastabend@...il.com>, Jakub Sitnicki <jakub@...udflare.com>, 
	"David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	David Ahern <dsahern@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Eduard Zingerman <eddyz87@...il.com>, Mykola Lysenko <mykolal@...com>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Shuah Khan <shuah@...nel.org>, Mykyta Yatsenko <yatsenko@...a.com>, Miao Xu <miaxu@...a.com>, 
	Yuran Pereira <yuran.pereira@...mail.com>, Geliang Tang <tanggeliang@...inos.cn>, 
	netdev@...r.kernel.org, bpf@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net 2/3] inet: null check for close in inet_release

On Mon, Jun 24, 2024 at 3:28 PM Geliang Tang <geliang@...nel.org> wrote:
>
> From: Geliang Tang <tanggeliang@...inos.cn>
>
> Run the following BPF selftests on loongarch:
>
> # ./test_progs -t sockmap_listen
>
> A Kernel panic occurs:
>
> '''
>  Oops[#1]:
>  CPU: 49 PID: 233429 Comm: new_name Tainted: G           OE      6.10.0-rc2+ #20
>  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018-V4.0.11
>  pc 0000000000000000 ra 90000000051ea4a0 tp 900030008549c000 sp 900030008549fe00
>  a0 9000300152524a00 a1 0000000000000000 a2 900030008549fe38 a3 900030008549fe30
>  a4 900030008549fe30 a5 90003000c58c8d80 a6 0000000000000000 a7 0000000000000039
>  t0 0000000000000000 t1 90003000c58c8d80 t2 0000000000000001 t3 0000000000000000
>  t4 0000000000000001 t5 900000011a1bf580 t6 900000011a3aff60 t7 000000000000006b
>  t8 00000fffffffffff u0 0000000000000000 s9 00007fffbbe9e930 s0 9000300152524a00
>  s1 90003000c58c8d00 s2 9000000006c81568 s3 0000000000000000 s4 90003000c58c8d80
>  s5 00007ffff236a000 s6 00007ffffbc292b0 s7 00007ffffbc29998 s8 00007fffbbe9f180
>     ra: 90000000051ea4a0 inet_release+0x60/0xc0
>    ERA: 0000000000000000 0x0
>   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
>   PRMD: 0000000c (PPLV0 +PIE +PWE)
>   EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
>   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
>  ESTAT: 00030000 [PIF] (IS= ECode=3 EsubCode=0)
>   BADV: 0000000000000000
>   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
>  Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp
>  Process new_name (pid: 233429, threadinfo=00000000b9196405, task=00000000c01df45b)
>  Stack : 0000000000000000 90003000c58c8e20 90003000c58c8d00 900000000505960c
>          0000000000000000 9000000101c6ad20 9000300086524540 00000000082e0003
>          900030008bf57400 90000000050596bc 900030008bf57400 900000000434acac
>          0000000000000016 00007ffff224e060 00007fffbbe9f180 900030008bf57400
>          0000000000000000 9000000004341ce0 00007fffbbe9f180 00007ffff2369000
>          900030008549fec0 90000000054476ec 000000000000006b 9000000003f71da4
>          000000000000003a 00007ffff22b8a44 00007fffbbe9f8e0 00007fffbbe9e680
>          ffffffffffffffda 0000000000000000 0000000000000000 0000000000000000
>          00007fffbbe9f288 0000000000000000 0000000000000000 0000000000000039
>          84c2431493ceab6e 84c23ceb2827425e 0000000000000007 00007ffff2271600
>          ...
>  Call Trace:
>  [<900000000505960c>] __sock_release+0x4c/0xe0
>  [<90000000050596bc>] sock_close+0x1c/0x40
>  [<900000000434acac>] __fput+0xec/0x2e0
>  [<9000000004341ce0>] sys_close+0x40/0xa0
>  [<90000000054476ec>] do_syscall+0x8c/0xc0
>  [<9000000003f71da4>] handle_syscall+0xc4/0x160
>
>  Code: (Bad address in era)
>
>  ---[ end trace 0000000000000000 ]---
>  Kernel panic - not syncing: Fatal exception
>  Kernel relocated by 0x3d50000
>   .text @ 0x9000000003f50000
>   .data @ 0x90000000055b0000
>   .bss  @ 0x9000000006ca9400
>  ---[ end Kernel panic - not syncing: Fatal exception ]---
> '''
>
> This is because "close" is NULL in that case. This patch adds null
> check for it in inet_release() to fix this error.
>

Please add a Fixes: tag, so that we can fully understand what is going on.

> Signed-off-by: Geliang Tang <tanggeliang@...inos.cn>
> ---
>  net/ipv4/af_inet.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index b24d74616637..8e926018d011 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -434,7 +434,8 @@ int inet_release(struct socket *sock)
>                 if (sock_flag(sk, SOCK_LINGER) &&
>                     !(current->flags & PF_EXITING))
>                         timeout = sk->sk_lingertime;
> -               sk->sk_prot->close(sk, timeout);
> +               if (sk->sk_prot && sk->sk_prot->close)

Which one is NULL exactly ?  sk->sk_prot or the ->close pointer ?

Why add all these checks if only one is requested ?

> +                       sk->sk_prot->close(sk, timeout);
>                 sock->sk = NULL;
>         }
>         return 0;
> --
> 2.43.0
>