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 <[email protected]>
Signed-off-by: Xie He <[email protected]>
---
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;
--
2.27.0
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 <[email protected]>
> Signed-off-by: Xie He <[email protected]>
> ---
> 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;
On Wed, Nov 11, 2020 at 3:41 AM Martin Schiller <[email protected]> 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.