diff mbox series

[net] net: x25: Fix kernel crashes due to x25_disconnect releasing x25_neigh

Message ID 20201111100424.3989-1-xie.he.0141@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [net] net: x25: Fix kernel crashes due to x25_disconnect releasing x25_neigh | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net
netdev/subject_prefix success Link
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 23 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Xie He Nov. 11, 2020, 10:04 a.m. UTC
The x25_disconnect function in x25_subr.c would decrease the refcount of
"x25->neighbour" (struct x25_neigh) and reset this pointer to NULL.

However:

1) When we receive a connection, the x25_rx_call_request function in
af_x25.c does not increase the refcount when it assigns the pointer.
When we disconnect, x25_disconnect is called and the struct's refcount
is decreased without being increased in the first place.

This causes frequent kernel crashes when using AF_X25 sockets.

2) When we initiate a connection but the connection is refused by the
remote side, x25_disconnect is called which decreases the refcount and
resets the pointer to NULL. But the x25_connect function in af_x25.c,
which is waiting for the connection to be established, notices the
failure and then tries to decrease the refcount again, resulting in a
NULL-pointer-dereference error.

This crashes the kernel every time a connection is refused by the remote
side.

Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Cc: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
---
 net/x25/af_x25.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Comments

Martin Schiller Nov. 11, 2020, 11:41 a.m. UTC | #1
On 2020-11-11 11:04, Xie He wrote:
> The x25_disconnect function in x25_subr.c would decrease the refcount 
> of
> "x25->neighbour" (struct x25_neigh) and reset this pointer to NULL.
> 
> However:
> 
> 1) When we receive a connection, the x25_rx_call_request function in
> af_x25.c does not increase the refcount when it assigns the pointer.
> When we disconnect, x25_disconnect is called and the struct's refcount
> is decreased without being increased in the first place.

Yes, this is a problem and should be fixed. As an alternative to your
approach, you could also go the way to prevent the call of
x25_neigh_put(nb) in x25_lapb_receive_frame() in case of a Call Request.
However, this would require more effort.

> 
> This causes frequent kernel crashes when using AF_X25 sockets.
> 
> 2) When we initiate a connection but the connection is refused by the
> remote side, x25_disconnect is called which decreases the refcount and
> resets the pointer to NULL. But the x25_connect function in af_x25.c,
> which is waiting for the connection to be established, notices the
> failure and then tries to decrease the refcount again, resulting in a
> NULL-pointer-dereference error.
> 
> This crashes the kernel every time a connection is refused by the 
> remote
> side.

For this bug I already sent a fix some time ago (last time I sent a
RESEND yesterday), but unfortunately it was not merged yet:
https://lore.kernel.org/patchwork/patch/1334917/

> 
> Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 
> disconnect")
> Cc: Martin Schiller <ms@dev.tdt.de>
> Signed-off-by: Xie He <xie.he.0141@gmail.com>
> ---
>  net/x25/af_x25.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
> index 0bbb283f23c9..8e59f9ecbeab 100644
> --- a/net/x25/af_x25.c
> +++ b/net/x25/af_x25.c
> @@ -826,10 +826,12 @@ static int x25_connect(struct socket *sock,
> struct sockaddr *uaddr,
>  	rc = 0;
>  out_put_neigh:
>  	if (rc) {
> -		read_lock_bh(&x25_list_lock);
> -		x25_neigh_put(x25->neighbour);
> -		x25->neighbour = NULL;
> -		read_unlock_bh(&x25_list_lock);
> +		if (x25->neighbour) {
> +			read_lock_bh(&x25_list_lock);
> +			x25_neigh_put(x25->neighbour);
> +			x25->neighbour = NULL;
> +			read_unlock_bh(&x25_list_lock);
> +		}
>  		x25->state = X25_STATE_0;
>  	}
>  out_put_route:
> @@ -1050,6 +1052,7 @@ int x25_rx_call_request(struct sk_buff *skb,
> struct x25_neigh *nb,
>  	makex25->lci           = lci;
>  	makex25->dest_addr     = dest_addr;
>  	makex25->source_addr   = source_addr;
> +	x25_neigh_hold(nb);
>  	makex25->neighbour     = nb;
>  	makex25->facilities    = facilities;
>  	makex25->dte_facilities= dte_facilities;
Xie He Nov. 11, 2020, 12:09 p.m. UTC | #2
On Wed, Nov 11, 2020 at 3:41 AM Martin Schiller <ms@dev.tdt.de> wrote:
>
> > 1) When we receive a connection, the x25_rx_call_request function in
> > af_x25.c does not increase the refcount when it assigns the pointer.
> > When we disconnect, x25_disconnect is called and the struct's refcount
> > is decreased without being increased in the first place.
>
> Yes, this is a problem and should be fixed. As an alternative to your
> approach, you could also go the way to prevent the call of
> x25_neigh_put(nb) in x25_lapb_receive_frame() in case of a Call Request.
> However, this would require more effort.

Yes, right. I think my approach is easier.

> > This causes frequent kernel crashes when using AF_X25 sockets.
> >
> > 2) When we initiate a connection but the connection is refused by the
> > remote side, x25_disconnect is called which decreases the refcount and
> > resets the pointer to NULL. But the x25_connect function in af_x25.c,
> > which is waiting for the connection to be established, notices the
> > failure and then tries to decrease the refcount again, resulting in a
> > NULL-pointer-dereference error.
> >
> > This crashes the kernel every time a connection is refused by the
> > remote
> > side.
>
> For this bug I already sent a fix some time ago (last time I sent a
> RESEND yesterday), but unfortunately it was not merged yet:
> https://lore.kernel.org/patchwork/patch/1334917/

I see. Thanks! Hope it will be merged soon!

I'll re-submit my patch without your part after your patch is merged.
diff mbox series

Patch

diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 0bbb283f23c9..8e59f9ecbeab 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -826,10 +826,12 @@  static int x25_connect(struct socket *sock, struct sockaddr *uaddr,
 	rc = 0;
 out_put_neigh:
 	if (rc) {
-		read_lock_bh(&x25_list_lock);
-		x25_neigh_put(x25->neighbour);
-		x25->neighbour = NULL;
-		read_unlock_bh(&x25_list_lock);
+		if (x25->neighbour) {
+			read_lock_bh(&x25_list_lock);
+			x25_neigh_put(x25->neighbour);
+			x25->neighbour = NULL;
+			read_unlock_bh(&x25_list_lock);
+		}
 		x25->state = X25_STATE_0;
 	}
 out_put_route:
@@ -1050,6 +1052,7 @@  int x25_rx_call_request(struct sk_buff *skb, struct x25_neigh *nb,
 	makex25->lci           = lci;
 	makex25->dest_addr     = dest_addr;
 	makex25->source_addr   = source_addr;
+	x25_neigh_hold(nb);
 	makex25->neighbour     = nb;
 	makex25->facilities    = facilities;
 	makex25->dte_facilities= dte_facilities;