netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Wang Liang <wangliang74@huawei.com>
Cc: chuck.lever@oracle.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, brauner@kernel.org,
	kernel-tls-handshake@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, yuehaibing@huawei.com,
	zhangchangzhong@huawei.com
Subject: Re: [PATCH net] net/handshake: Fix null-ptr-deref in handshake_complete()
Date: Tue, 9 Dec 2025 18:06:46 +0000	[thread overview]
Message-ID: <aThlNuc-kjPqd9kh@horms.kernel.org> (raw)
In-Reply-To: <20251209115852.3827876-1-wangliang74@huawei.com>

On Tue, Dec 09, 2025 at 07:58:52PM +0800, Wang Liang wrote:
> A null pointer dereference in handshake_complete() was observed [1].
> 
> When handshake_req_next() return NULL in handshake_nl_accept_doit(),
> function handshake_complete() will be called unexpectedly which triggers
> this crash. Fix it by goto out_status when req is NULL.
> 
> [1]
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI
> RIP: 0010:handshake_complete+0x36/0x2b0 net/handshake/request.c:288
> Call Trace:
>  <TASK>
>  handshake_nl_accept_doit+0x32d/0x7e0 net/handshake/netlink.c:129
>  genl_family_rcv_msg_doit+0x204/0x300 net/netlink/genetlink.c:1115
>  genl_family_rcv_msg+0x436/0x670 net/netlink/genetlink.c:1195
>  genl_rcv_msg+0xcc/0x170 net/netlink/genetlink.c:1210
>  netlink_rcv_skb+0x14c/0x430 net/netlink/af_netlink.c:2550
>  genl_rcv+0x2d/0x40 net/netlink/genetlink.c:1219
>  netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
>  netlink_unicast+0x878/0xb20 net/netlink/af_netlink.c:1344
>  netlink_sendmsg+0x897/0xd70 net/netlink/af_netlink.c:1894
>  sock_sendmsg_nosec net/socket.c:727 [inline]
>  __sock_sendmsg net/socket.c:742 [inline]
>  ____sys_sendmsg+0xa39/0xbf0 net/socket.c:2592
>  ___sys_sendmsg+0x121/0x1c0 net/socket.c:2646
>  __sys_sendmsg+0x155/0x200 net/socket.c:2678
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0x5f/0x350 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>  </TASK>
> 
> Fixes: fe67b063f687 ("net/handshake: convert handshake_nl_accept_doit() to FD_PREPARE()")
> Signed-off-by: Wang Liang <wangliang74@huawei.com>
> ---
>  net/handshake/netlink.c | 35 ++++++++++++++++++-----------------
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/net/handshake/netlink.c b/net/handshake/netlink.c
> index 1d33a4675a48..cdaea8b8d004 100644
> --- a/net/handshake/netlink.c
> +++ b/net/handshake/netlink.c
> @@ -106,25 +106,26 @@ int handshake_nl_accept_doit(struct sk_buff *skb, struct genl_info *info)
>  
>  	err = -EAGAIN;
>  	req = handshake_req_next(hn, class);
> -	if (req) {
> -		sock = req->hr_sk->sk_socket;
> -
> -		FD_PREPARE(fdf, O_CLOEXEC, sock->file);
> -		if (fdf.err) {
> -			err = fdf.err;
> -			goto out_complete;
> -		}
> -
> -		get_file(sock->file); /* FD_PREPARE() consumes a reference. */
> -		err = req->hr_proto->hp_accept(req, info, fd_prepare_fd(fdf));
> -		if (err)
> -			goto out_complete; /* Automatic cleanup handles fput */
> -
> -		trace_handshake_cmd_accept(net, req, req->hr_sk, fd_prepare_fd(fdf));
> -		fd_publish(fdf);
> -		return 0;
> +	if (!req)
> +		goto out_status;
> +
> +	sock = req->hr_sk->sk_socket;
> +
> +	FD_PREPARE(fdf, O_CLOEXEC, sock->file);
> +	if (fdf.err) {
> +		err = fdf.err;
> +		goto out_complete;
>  	}
>  
> +	get_file(sock->file); /* FD_PREPARE() consumes a reference. */
> +	err = req->hr_proto->hp_accept(req, info, fd_prepare_fd(fdf));
> +	if (err)
> +		goto out_complete; /* Automatic cleanup handles fput */
> +
> +	trace_handshake_cmd_accept(net, req, req->hr_sk, fd_prepare_fd(fdf));
> +	fd_publish(fdf);
> +	return 0;
> +
>  out_complete:
>  	handshake_complete(req, -EIO, NULL);
>  out_status:

Hi,

Clang 21.1.7 W=1 builds are rather unhappy about this:

  net/handshake/netlink.c:110:3: error: cannot jump from this goto statement to its label
    110 |                 goto out_status;
        |                 ^
  net/handshake/netlink.c:114:13: note: jump bypasses initialization of variable with __attribute__((cleanup))
    114 |         FD_PREPARE(fdf, O_CLOEXEC, sock->file);
        |                    ^
  net/handshake/netlink.c:104:3: error: cannot jump from this goto statement to its label
    104 |                 goto out_status;
        |                 ^
  net/handshake/netlink.c:114:13: note: jump bypasses initialization of variable with __attribute__((cleanup))
    114 |         FD_PREPARE(fdf, O_CLOEXEC, sock->file);
        |                    ^
  net/handshake/netlink.c:100:3: error: cannot jump from this goto statement to its label
    100 |                 goto out_status;
        |                 ^
  net/handshake/netlink.c:114:13: note: jump bypasses initialization of variable with __attribute__((cleanup))
    114 |         FD_PREPARE(fdf, O_CLOEXEC, sock->file);
        |                    ^

My undersatnding of the problem is as follows:

FD_PREPARE uses __cleanup to call class_fd_prepare_destructor when
resources when fdf goes out of scope.

Prior to this patch this was when the if (req) block was existed.
Either via return or a goto due to an error.

Now it is when handshake_nl_accept_doit() itself is exited.
Again via a return or a goto due to error.

But, importantly, such a goto can now occur before fdf is initialised.
Boom!

-- 
pw-bot: changes-requested

  parent reply	other threads:[~2025-12-09 18:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09 11:58 [PATCH net] net/handshake: Fix null-ptr-deref in handshake_complete() Wang Liang
2025-12-09 14:39 ` Chuck Lever
2025-12-10  2:50   ` Wang Liang
2025-12-09 18:06 ` Simon Horman [this message]
2025-12-10  2:51   ` Wang Liang
2025-12-10 10:08     ` Simon Horman
2025-12-10  1:36 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aThlNuc-kjPqd9kh@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kernel-tls-handshake@lists.linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wangliang74@huawei.com \
    --cc=yuehaibing@huawei.com \
    --cc=zhangchangzhong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).