tipc-discussion — User questions & problem reports, project news, developer discussion

[tipc-discussion] A slow message receiver member slowing the group multicasting for all members

[Asebot F. A. <aby...@gm...>]

Hi folks,

I'd like to understand the expected behavior when a member of a group is
slow to pick up a group multicast/broadcast message. From what I'm
observing on my testing, it seem to slow down the whole messaging bus.
Please confirm and advise on a workaround if any.

Thanks,

Asebot

Re: [tipc-discussion] [PATCH v1 1/1] tipc: fix unexpected link reset due to discovery messages

[Jon M. <jm...@re...>]

On 1/3/23 21:42, Tung Nguyen wrote:
> This unexpected behavior is observed:
>
> node 1                    | node 2
> ------                    | ------
> link is established       | link is established
> reboot                    | link is reset
> up                        | send discovery message
> receive discovery message |
> link is established       | link is established
> send discovery message    |
>                            | receive discovery message
>                            | link is reset (unexpected)
>                            | send reset message
> link is reset             |
>
> It is due to delayed re-discovery as described in function
> tipc_node_check_dest(): "this link endpoint has already reset
> and re-established contact with the peer, before receiving a
> discovery message from that node."
>
> However, commit 598411d70f85 has changed the condition for calling
> tipc_node_link_down() which was the acceptance of new media address.
>
> This commit fixes this by restoring the old and correct behavior.
>
> Fixes: 598411d70f85 ("tipc: make link implementation independent from struct tipc_bearer")
> Signed-off-by: Tung Nguyen <tun...@de...>
> ---
>   net/tipc/node.c | 12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/tipc/node.c b/net/tipc/node.c
> index 49ddc484c4fe..5e000fde8067 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -1179,8 +1179,9 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   	bool addr_match = false;
>   	bool sign_match = false;
>   	bool link_up = false;
> +	bool link_is_reset = false;
>   	bool accept_addr = false;
> -	bool reset = true;
> +	bool reset = false;
>   	char *if_name;
>   	unsigned long intv;
>   	u16 session;
> @@ -1200,14 +1201,14 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   	/* Prepare to validate requesting node's signature and media address */
>   	l = le->link;
>   	link_up = l && tipc_link_is_up(l);
> +	link_is_reset = l && tipc_link_is_reset(l);
>   	addr_match = l && !memcmp(&le->maddr, maddr, sizeof(*maddr));
>   	sign_match = (signature == n->signature);
>   
>   	/* These three flags give us eight permutations: */
>   
>   	if (sign_match && addr_match && link_up) {
> -		/* All is fine. Do nothing. */
> -		reset = false;
> +		/* All is fine. Ignore requests. */
>   		/* Peer node is not a container/local namespace */
>   		if (!n->peer_hash_mix)
>   			n->peer_hash_mix = hash_mixes;
> @@ -1232,6 +1233,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   		 */
>   		accept_addr = true;
>   		*respond = true;
> +		reset = true;
>   	} else if (!sign_match && addr_match && link_up) {
>   		/* Peer node rebooted. Two possibilities:
>   		 *  - Delayed re-discovery; this link endpoint has already
> @@ -1263,6 +1265,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   		n->signature = signature;
>   		accept_addr = true;
>   		*respond = true;
> +		reset = true;
>   	}
>   
>   	if (!accept_addr)
> @@ -1291,6 +1294,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   		tipc_link_fsm_evt(l, LINK_RESET_EVT);
>   		if (n->state == NODE_FAILINGOVER)
>   			tipc_link_fsm_evt(l, LINK_FAILOVER_BEGIN_EVT);
> +		link_is_reset = tipc_link_is_reset(l);
>   		le->link = l;
>   		n->link_cnt++;
>   		tipc_node_calculate_timer(n, l);
> @@ -1303,7 +1307,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   	memcpy(&le->maddr, maddr, sizeof(*maddr));
>   exit:
>   	tipc_node_write_unlock(n);
> -	if (reset && l && !tipc_link_is_reset(l))
> +	if (reset && !link_is_reset)
>   		tipc_node_link_down(n, b->identity, false);
>   	tipc_node_put(n);
>   }

Acked-by: Jon Maloy <jm...@re...>
Nice job!

[tipc-discussion] [PATCH v1 1/1] tipc: fix unexpected link reset due to discovery messages

[Tung N. <tun...@de...>]

This unexpected behavior is observed:

node 1                    | node 2
------                    | ------
link is established       | link is established
reboot                    | link is reset
up                        | send discovery message
receive discovery message |
link is established       | link is established
send discovery message    |
                          | receive discovery message
                          | link is reset (unexpected)
                          | send reset message
link is reset             |

It is due to delayed re-discovery as described in function
tipc_node_check_dest(): "this link endpoint has already reset
and re-established contact with the peer, before receiving a
discovery message from that node."

However, commit 598411d70f85 has changed the condition for calling
tipc_node_link_down() which was the acceptance of new media address.

This commit fixes this by restoring the old and correct behavior.

Fixes: 598411d70f85 ("tipc: make link implementation independent from struct tipc_bearer")
Signed-off-by: Tung Nguyen <tun...@de...>
---
 net/tipc/node.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/net/tipc/node.c b/net/tipc/node.c
index 49ddc484c4fe..5e000fde8067 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1179,8 +1179,9 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 	bool addr_match = false;
 	bool sign_match = false;
 	bool link_up = false;
+	bool link_is_reset = false;
 	bool accept_addr = false;
-	bool reset = true;
+	bool reset = false;
 	char *if_name;
 	unsigned long intv;
 	u16 session;
@@ -1200,14 +1201,14 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 	/* Prepare to validate requesting node's signature and media address */
 	l = le->link;
 	link_up = l && tipc_link_is_up(l);
+	link_is_reset = l && tipc_link_is_reset(l);
 	addr_match = l && !memcmp(&le->maddr, maddr, sizeof(*maddr));
 	sign_match = (signature == n->signature);
 
 	/* These three flags give us eight permutations: */
 
 	if (sign_match && addr_match && link_up) {
-		/* All is fine. Do nothing. */
-		reset = false;
+		/* All is fine. Ignore requests. */
 		/* Peer node is not a container/local namespace */
 		if (!n->peer_hash_mix)
 			n->peer_hash_mix = hash_mixes;
@@ -1232,6 +1233,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 		 */
 		accept_addr = true;
 		*respond = true;
+		reset = true;
 	} else if (!sign_match && addr_match && link_up) {
 		/* Peer node rebooted. Two possibilities:
 		 *  - Delayed re-discovery; this link endpoint has already
@@ -1263,6 +1265,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 		n->signature = signature;
 		accept_addr = true;
 		*respond = true;
+		reset = true;
 	}
 
 	if (!accept_addr)
@@ -1291,6 +1294,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 		tipc_link_fsm_evt(l, LINK_RESET_EVT);
 		if (n->state == NODE_FAILINGOVER)
 			tipc_link_fsm_evt(l, LINK_FAILOVER_BEGIN_EVT);
+		link_is_reset = tipc_link_is_reset(l);
 		le->link = l;
 		n->link_cnt++;
 		tipc_node_calculate_timer(n, l);
@@ -1303,7 +1307,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 	memcpy(&le->maddr, maddr, sizeof(*maddr));
 exit:
 	tipc_node_write_unlock(n);
-	if (reset && l && !tipc_link_is_reset(l))
+	if (reset && !link_is_reset)
 		tipc_node_link_down(n, b->identity, false);
 	tipc_node_put(n);
 }
-- 
2.34.1

Re: [tipc-discussion] TIPC Packet statistics

[Jon M. <jm...@re...>]

On 12/13/22 02:30, Harish Chandrasekaran wrote:
> Hello all,
>
> I'm looking for a utility/command to get the tipc packet/connection
> information while running the client and server within the same
> card/kernel.
>
> The "tipc link statistics show" gives some insights regarding the packets
> across the bearers
> Link <10300411:BEARER1-10300431:BEARER-2>
>    ACTIVE  MTU:14000  Priority:10  Tolerance:1500 ms  Window:50 packets
>    RX packets:9013188 fragments:0/0 bundles:0/0
>    TX packets:9430977 fragments:760/190 bundles:0/0
>    TX profile sample:613736 packets average:42 octets
>    0-64:93% -256:7% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0%
>    RX states:2155490 probes:423110 naks:8365 defs:11806 dups:11875
>    TX states:2199617 probes:413191 naks:11866 acks:290 retrans:8371
>    Congestion link:0  Send queue max:0 avg:0
>
>
> I'm looking for something similar to the above or something similar to what
> netstat provides for tcp packets/connections with in the same card/machine
>
> netstat -s
> Tcp:
>      1312727 active connection openings
>      325217 passive connection openings
>      987300 failed connection attempts
>      9 connection resets received
>      41 connections established
>      84939296 segments received
>      86976822 segments sent out
>      985790 segments retransmitted
>      0 bad segments received
>      1821 resets sent
>
> Eg: The  hello_server and hello_client run on the same machine. I would
> like to check if there are any naks or duplicates or packet drops or if
> there are any connection resets or failed connection attempts.
>
> I tried to check if *netstat statistics *captures TIPC connection related
> information but it doesn't seem to capture the TIPC related info.
>
> Kindly let me know if there are any utilities or TIPC commands which I can
> use to gather such information?
>
> Would greatly appreciate any help.
>
> Sincerely,
> Harish

Hi,
Sorry for a late answer.
It is actually possible to observe node internal traffic with 
tcpdump/wireshark
if  you activate network taps for the loopback device.
The following commit explains it:

commit 6c9081a3915dc0782a8f1424343b794f2cf53d9c
Author: John Rutherford <joh...@de...>
Date:   Wed Aug 7 12:52:29 2019 +1000

     tipc: add loopback device tracking

     Since node internal messages are passed directly to the socket, it 
is not
     possible to observe those messages via tcpdump or wireshark.

     We now remedy this by making it possible to clone such messages and 
send
     the clones to the loopback interface.  The clones are dropped at 
reception
     and have no functional role except making the traffic visible.

     The feature is enabled if network taps are active for the loopback 
device.
     pcap filtering restrictions require the messages to be presented to the
     receiving side of the loopback device.

     v3 - Function dev_nit_active used to check for network taps.
        - Procedure netif_rx_ni used to send cloned messages to loopback 
device.

     Signed-off-by: John Rutherford <joh...@de...>
     Acked-by: Jon Maloy <jon...@er...>
     Acked-by: Ying Xue <yin...@wi...>
     Signed-off-by: David S. Miller <da...@da...>


Thanks
///jon


>
> _______________________________________________
> tipc-discussion mailing list
> tip...@li...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>

[tipc-discussion] TIPC Packet statistics

[Harish C. <har...@gm...>]

Hello all,

I'm looking for a utility/command to get the tipc packet/connection
information while running the client and server within the same
card/kernel.

The "tipc link statistics show" gives some insights regarding the packets
across the bearers
Link <10300411:BEARER1-10300431:BEARER-2>
  ACTIVE  MTU:14000  Priority:10  Tolerance:1500 ms  Window:50 packets
  RX packets:9013188 fragments:0/0 bundles:0/0
  TX packets:9430977 fragments:760/190 bundles:0/0
  TX profile sample:613736 packets average:42 octets
  0-64:93% -256:7% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0%
  RX states:2155490 probes:423110 naks:8365 defs:11806 dups:11875
  TX states:2199617 probes:413191 naks:11866 acks:290 retrans:8371
  Congestion link:0  Send queue max:0 avg:0


I'm looking for something similar to the above or something similar to what
netstat provides for tcp packets/connections with in the same card/machine

netstat -s
Tcp:
    1312727 active connection openings
    325217 passive connection openings
    987300 failed connection attempts
    9 connection resets received
    41 connections established
    84939296 segments received
    86976822 segments sent out
    985790 segments retransmitted
    0 bad segments received
    1821 resets sent

Eg: The  hello_server and hello_client run on the same machine. I would
like to check if there are any naks or duplicates or packet drops or if
there are any connection resets or failed connection attempts.

I tried to check if *netstat statistics *captures TIPC connection related
information but it doesn't seem to capture the TIPC related info.

Kindly let me know if there are any utilities or TIPC commands which I can
use to gather such information?

Would greatly appreciate any help.

Sincerely,
Harish

[tipc-discussion] [PATCH net] tipc: re-fetch skb cb after tipc_msg_validate

[Xin L. <luc...@gm...>]

As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.

  BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
  Call Trace:
   <IRQ>
   tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]
  ...
  Allocated by task 47078:
   kmem_cache_alloc_node+0x158/0x4d0
   __alloc_skb+0x1c1/0x270
   tipc_buf_acquire+0x1e/0xe0 [tipc]
   tipc_msg_create+0x33/0x1c0 [tipc]
   tipc_link_build_proto_msg+0x38a/0x2100 [tipc]
   tipc_link_timeout+0x8b8/0xef0 [tipc]
   tipc_node_timeout+0x2a1/0x960 [tipc]
   call_timer_fn+0x2d/0x1c0
  ...
  Freed by task 47078:
   tipc_msg_validate+0x7b/0x440 [tipc]
   tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]

This patch fixes it by re-fetching the skb cb from the new allocated skb
after calling tipc_msg_validate().

Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Reported-by: Shuang Li <sh...@re...>
Signed-off-by: Xin Long <luc...@gm...>
---
 net/tipc/crypto.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index f09316a9035f..d67440de011e 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -1971,6 +1971,9 @@ static void tipc_crypto_rcv_complete(struct net *net, struct tipc_aead *aead,
 	/* Ok, everything's fine, try to synch own keys according to peers' */
 	tipc_crypto_key_synch(rx, *skb);
 
+	/* Re-fetch skb cb as skb might be changed in tipc_msg_validate */
+	skb_cb = TIPC_SKB_CB(*skb);
+
 	/* Mark skb decrypted */
 	skb_cb->decrypted = 1;
 
-- 
2.31.1

Re: [tipc-discussion] [PATCH net] tipc: check skb_linearize() return value in tipc_disc_rcv()

[Jon M. <jm...@re...>]

On 11/19/22 02:28, YueHaibing wrote:
> If skb_linearize() fails in tipc_disc_rcv(), we need to free the skb instead of
> handle it.
>
> Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values")
> Signed-off-by: YueHaibing <yue...@hu...>
> ---
>   net/tipc/discover.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/discover.c b/net/tipc/discover.c
> index e8630707901e..e8dcdf267c0c 100644
> --- a/net/tipc/discover.c
> +++ b/net/tipc/discover.c
> @@ -211,7 +211,10 @@ void tipc_disc_rcv(struct net *net, struct sk_buff *skb,
>   	u32 self;
>   	int err;
>   
> -	skb_linearize(skb);
> +	if (skb_linearize(skb)) {
> +		kfree_skb(skb);
> +		return;
> +	}
>   	hdr = buf_msg(skb);
>   
>   	if (caps & TIPC_NODE_ID128)
Acked-by: Jon Maloy <jm...@re...>

Re: [tipc-discussion] [PATCH net 0/2] tipc: fix two race issues in tipc_conn_alloc

[Jon M. <jm...@re...>]

On 11/18/22 16:44, Xin Long wrote:
> The race exists beteen tipc_topsrv_accept() and tipc_conn_close(),
> one is allocating the con while the other is freeing it and there
> is no proper lock protecting it. Therefore, a null-pointer-defer
> and a use-after-free may be triggered, see details on each patch.
>
> Xin Long (2):
>    tipc: set con sock in tipc_conn_alloc
>    tipc: add an extra conn_get in tipc_conn_alloc
>
>   net/tipc/topsrv.c | 20 +++++++++++---------
>   1 file changed, 11 insertions(+), 9 deletions(-)
>
Series
Acked-by: Jon Maloy <jm...@re...>

[tipc-discussion] [PATCH net 1/2] tipc: set con sock in tipc_conn_alloc

[Xin L. <luc...@gm...>]

A crash was reported by Wei Chen:

  BUG: kernel NULL pointer dereference, address: 0000000000000018
  RIP: 0010:tipc_conn_close+0x12/0x100
  Call Trace:
   tipc_topsrv_exit_net+0x139/0x320
   ops_exit_list.isra.9+0x49/0x80
   cleanup_net+0x31a/0x540
   process_one_work+0x3fa/0x9f0
   worker_thread+0x42/0x5c0

It was caused by !con->sock in tipc_conn_close(). In tipc_topsrv_accept(),
con is allocated in conn_idr then its sock is set:

  con = tipc_conn_alloc();
  ...                    <----[1]
  con->sock = newsock;

If tipc_conn_close() is called in anytime of [1], the null-pointer-def
is triggered by con->sock->sk due to con->sock is not yet set.

This patch fixes it by moving the con->sock setting to tipc_conn_alloc()
under s->idr_lock. So that con->sock can never be NULL when getting the
con from s->conn_idr. It will be also safer to move con->server and flag
CF_CONNECTED setting under s->idr_lock, as they should all be set before
tipc_conn_alloc() is called.

Fixes: c5fa7b3cf3cb ("tipc: introduce new TIPC server infrastructure")
Reported-by: Wei Chen <har...@gm...>
Signed-off-by: Xin Long <luc...@gm...>
---
 net/tipc/topsrv.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index d92ec92f0b71..b0f9aa521670 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -176,7 +176,7 @@ static void tipc_conn_close(struct tipc_conn *con)
 	conn_put(con);
 }
 
-static struct tipc_conn *tipc_conn_alloc(struct tipc_topsrv *s)
+static struct tipc_conn *tipc_conn_alloc(struct tipc_topsrv *s, struct socket *sock)
 {
 	struct tipc_conn *con;
 	int ret;
@@ -202,10 +202,11 @@ static struct tipc_conn *tipc_conn_alloc(struct tipc_topsrv *s)
 	}
 	con->conid = ret;
 	s->idr_in_use++;
-	spin_unlock_bh(&s->idr_lock);
 
 	set_bit(CF_CONNECTED, &con->flags);
 	con->server = s;
+	con->sock = sock;
+	spin_unlock_bh(&s->idr_lock);
 
 	return con;
 }
@@ -467,7 +468,7 @@ static void tipc_topsrv_accept(struct work_struct *work)
 		ret = kernel_accept(lsock, &newsock, O_NONBLOCK);
 		if (ret < 0)
 			return;
-		con = tipc_conn_alloc(srv);
+		con = tipc_conn_alloc(srv, newsock);
 		if (IS_ERR(con)) {
 			ret = PTR_ERR(con);
 			sock_release(newsock);
@@ -479,7 +480,6 @@ static void tipc_topsrv_accept(struct work_struct *work)
 		newsk->sk_data_ready = tipc_conn_data_ready;
 		newsk->sk_write_space = tipc_conn_write_space;
 		newsk->sk_user_data = con;
-		con->sock = newsock;
 		write_unlock_bh(&newsk->sk_callback_lock);
 
 		/* Wake up receive process in case of 'SYN+' message */
@@ -577,12 +577,11 @@ bool tipc_topsrv_kern_subscr(struct net *net, u32 port, u32 type, u32 lower,
 	sub.filter = filter;
 	*(u64 *)&sub.usr_handle = (u64)port;
 
-	con = tipc_conn_alloc(tipc_topsrv(net));
+	con = tipc_conn_alloc(tipc_topsrv(net), NULL);
 	if (IS_ERR(con))
 		return false;
 
 	*conid = con->conid;
-	con->sock = NULL;
 	rc = tipc_conn_rcv_sub(tipc_topsrv(net), con, &sub);
 	if (rc >= 0)
 		return true;
-- 
2.31.1

[tipc-discussion] [PATCH net 2/2] tipc: add an extra conn_get in tipc_conn_alloc

[Xin L. <luc...@gm...>]

One extra conn_get() is needed in tipc_conn_alloc(), as after
tipc_conn_alloc() is called, tipc_conn_close() may free this
con before deferencing it in tipc_topsrv_accept():

   tipc_conn_alloc();
   newsk = newsock->sk;
                                 <---- tipc_conn_close();
   write_lock_bh(&sk->sk_callback_lock);
   newsk->sk_data_ready = tipc_conn_data_ready;

Then an uaf issue can be triggered:

  BUG: KASAN: use-after-free in tipc_topsrv_accept+0x1e7/0x370 [tipc]
  Call Trace:
   <TASK>
   dump_stack_lvl+0x33/0x46
   print_report+0x178/0x4b0
   kasan_report+0x8c/0x100
   kasan_check_range+0x179/0x1e0
   tipc_topsrv_accept+0x1e7/0x370 [tipc]
   process_one_work+0x6a3/0x1030
   worker_thread+0x8a/0xdf0

This patch fixes it by holding it in tipc_conn_alloc(), then after
all accessing in tipc_topsrv_accept() releasing it. Note when does
this in tipc_topsrv_kern_subscr(), as tipc_conn_rcv_sub() returns
0 or -1 only, we don't need to check for "> 0".

Fixes: c5fa7b3cf3cb ("tipc: introduce new TIPC server infrastructure")
Signed-off-by: Xin Long <luc...@gm...>
---
 net/tipc/topsrv.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index b0f9aa521670..e3b427a70398 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -206,6 +206,7 @@ static struct tipc_conn *tipc_conn_alloc(struct tipc_topsrv *s, struct socket *s
 	set_bit(CF_CONNECTED, &con->flags);
 	con->server = s;
 	con->sock = sock;
+	conn_get(con);
 	spin_unlock_bh(&s->idr_lock);
 
 	return con;
@@ -484,6 +485,7 @@ static void tipc_topsrv_accept(struct work_struct *work)
 
 		/* Wake up receive process in case of 'SYN+' message */
 		newsk->sk_data_ready(newsk);
+		conn_put(con);
 	}
 }
 
@@ -583,10 +585,11 @@ bool tipc_topsrv_kern_subscr(struct net *net, u32 port, u32 type, u32 lower,
 
 	*conid = con->conid;
 	rc = tipc_conn_rcv_sub(tipc_topsrv(net), con, &sub);
-	if (rc >= 0)
-		return true;
+	if (rc)
+		conn_put(con);
+
 	conn_put(con);
-	return false;
+	return !rc;
 }
 
 void tipc_topsrv_kern_unsubscr(struct net *net, int conid)
-- 
2.31.1

[tipc-discussion] [PATCH net 0/2] tipc: fix two race issues in tipc_conn_alloc

[Xin L. <luc...@gm...>]

The race exists beteen tipc_topsrv_accept() and tipc_conn_close(),
one is allocating the con while the other is freeing it and there
is no proper lock protecting it. Therefore, a null-pointer-defer
and a use-after-free may be triggered, see details on each patch.

Xin Long (2):
  tipc: set con sock in tipc_conn_alloc
  tipc: add an extra conn_get in tipc_conn_alloc

 net/tipc/topsrv.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

-- 
2.31.1

[tipc-discussion] [PATCH net] tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header

[Xin L. <luc...@gm...>]

This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value
in tipc_nl_compat_name_table_dump") where it should have type casted
sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative
value.

syzbot reported a call trace because of it:

  BUG: KMSAN: uninit-value in ...
   tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934
   __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238
   tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321
   tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324
   genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
   genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
   genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
   netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
   genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
   netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
   netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
   netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
   sock_sendmsg_nosec net/socket.c:714 [inline]
   sock_sendmsg net/socket.c:734 [inline]

Reported-by: syz...@sy...
Fixes: 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump")
Signed-off-by: Xin Long <luc...@gm...>
---
 net/tipc/netlink_compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index fc68733673ba..dfea27a906f2 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -880,7 +880,7 @@ static int tipc_nl_compat_name_table_dump_header(struct tipc_nl_compat_msg *msg)
 	};
 
 	ntq = (struct tipc_name_table_query *)TLV_DATA(msg->req);
-	if (TLV_GET_DATA_LEN(msg->req) < sizeof(struct tipc_name_table_query))
+	if (TLV_GET_DATA_LEN(msg->req) < (int)sizeof(struct tipc_name_table_query))
 		return -EINVAL;
 
 	depth = ntohl(ntq->depth);
-- 
2.31.1

Re: [tipc-discussion] BUG: unable to handle kernel NULL pointer dereference in tipc_crypto_key_distr

[Xin L. <luc...@gm...>]

On Sun, Oct 30, 2022 at 6:32 AM Wei Chen <har...@gm...> wrote:
>
> Dear Linux Developer,
>
> Recently when using our tool to fuzz kernel, the following crash was triggered:
>
> HEAD commit: 64570fbc14f8 Linux 5.15-rc5
> git tree: upstream
> compiler: gcc 8.0.1
> console output:
> https://drive.google.com/file/d/1ZxNXcUkiJiTK6MzVIWCqDpq70QW2-t-b/view?usp=share_link
> kernel config: https://drive.google.com/file/d/1uDOeEYgJDcLiSOrx9W8v2bqZ6uOA_55t/view?usp=share_link
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: Wei Chen <har...@gm...>
>
> RBP: 0000000000000045 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000119bfac
> R13: 0000000000000000 R14: 000000000119bfa0 R15: 00007fffcffa6fe0
> BUG: kernel NULL pointer dereference, address: 0000000000000020
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 2763b067 P4D 2763b067 PUD 27636067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP
> CPU: 0 PID: 12346 Comm: syz-executor.0 Not tainted 5.15.0-rc5 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
> RIP: 0010:tipc_crypto_key_distr+0x121/0x6a0
> Code: 00 48 8b 13 88 85 60 ff ff ff 41 0f b7 44 24 48 48 89 95 68 ff
> ff ff 66 89 85 5c ff ff ff 49 8b 44 24 40 48 89 85 50 ff ff ff <8b> 40
> 20 83 c0 24 0f b7 c0 83 c0 28 89 c7 89 85 64 ff ff ff e8 96
> RSP: 0018:ffffc9000d48f8e0 EFLAGS: 00010212
> RAX: 0000000000000000 RBX: ffff888010979a00 RCX: 0000000000040000
> RDX: ffff8880163e0000 RSI: 0000000000000a20 RDI: 0000000000000002
> RBP: ffffc9000d48f998 R08: ffffffff847c7f3d R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000001 R12: ffff88803189eb00
> R13: 0000000000000001 R14: 0000000000000000 R15: 00000000ffffff82
> FS:  00007f54fc3f7700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000020 CR3: 0000000027638000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  tipc_nl_node_set_key+0x760/0x930
Please check if this fix is in your kernel:

commit 3e6db079751afd527bf3db32314ae938dc571916
Author: Tadeusz Struk <tad...@li...>
Date:   Mon Nov 15 08:01:43 2021 -0800

    tipc: check for null after calling kmemdup

Thanks.
>  genl_family_rcv_msg_doit.isra.16+0x141/0x190
>  genl_rcv_msg+0x172/0x2c0
>  netlink_rcv_skb+0x87/0x1d0
>  genl_rcv+0x24/0x40
>  netlink_unicast+0x2b8/0x3d0
>  netlink_sendmsg+0x350/0x680
>  sock_sendmsg+0x52/0x70
>  ____sys_sendmsg+0x35f/0x390
>  ___sys_sendmsg+0x95/0xd0
>  __sys_sendmsg+0x87/0x100
>  do_syscall_64+0x34/0xb0
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x4692c9
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f54fc3f6c38 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00007f54fc3f6c80 RCX: 00000000004692c9
> RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003
> RBP: 0000000000000045 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000119bfac
> R13: 0000000000000000 R14: 000000000119bfa0 R15: 00007fffcffa6fe0
> Modules linked in:
> CR2: 0000000000000020
> ---[ end trace c7813f5e0b2eeeab ]---
> RIP: 0010:tipc_crypto_key_distr+0x121/0x6a0
> Code: 00 48 8b 13 88 85 60 ff ff ff 41 0f b7 44 24 48 48 89 95 68 ff
> ff ff 66 89 85 5c ff ff ff 49 8b 44 24 40 48 89 85 50 ff ff ff <8b> 40
> 20 83 c0 24 0f b7 c0 83 c0 28 89 c7 89 85 64 ff ff ff e8 96
> RSP: 0018:ffffc9000d48f8e0 EFLAGS: 00010212
> RAX: 0000000000000000 RBX: ffff888010979a00 RCX: 0000000000040000
> RDX: ffff8880163e0000 RSI: 0000000000000a20 RDI: 0000000000000002
> RBP: ffffc9000d48f998 R08: ffffffff847c7f3d R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000001 R12: ffff88803189eb00
> R13: 0000000000000001 R14: 0000000000000000 R15: 00000000ffffff82
> FS:  00007f54fc3f7700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000020 CR3: 0000000027638000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
>    0: 00 48 8b              add    %cl,-0x75(%rax)
>    3: 13 88 85 60 ff ff    adc    -0x9f7b(%rax),%ecx
>    9: ff 41 0f              incl   0xf(%rcx)
>    c: b7 44                mov    $0x44,%bh
>    e: 24 48                and    $0x48,%al
>   10: 48 89 95 68 ff ff ff mov    %rdx,-0x98(%rbp)
>   17: 66 89 85 5c ff ff ff mov    %ax,-0xa4(%rbp)
>   1e: 49 8b 44 24 40        mov    0x40(%r12),%rax
>   23: 48 89 85 50 ff ff ff mov    %rax,-0xb0(%rbp)
> * 2a: 8b 40 20              mov    0x20(%rax),%eax <-- trapping instruction
>   2d: 83 c0 24              add    $0x24,%eax
>   30: 0f b7 c0              movzwl %ax,%eax
>   33: 83 c0 28              add    $0x28,%eax
>   36: 89 c7                mov    %eax,%edi
>   38: 89 85 64 ff ff ff    mov    %eax,-0x9c(%rbp)
>   3e: e8                    .byte 0xe8
>   3f: 96                    xchg   %eax,%esi
>
> Best,
> We

Re: [tipc-discussion] BUG: unable to handle kernel NULL pointer dereference in tipc_conn_close

[Xin L. <luc...@gm...>]

On Sun, Oct 30, 2022 at 6:20 AM Wei Chen <har...@gm...> wrote:
>
> Dear Linux Developer,
>
> Recently when using our tool to fuzz kernel, the following crash was triggered:
>
> HEAD commit: 64570fbc14f8 Linux 5.15-rc5
> git tree: upstream
> compiler: gcc 8.0.1
> console output:
> https://drive.google.com/file/d/1nDvjcSyhzWncMlR35k1P1dC8rswJ_Zin/view?usp=share_link
> kernel config: https://drive.google.com/file/d/1uDOeEYgJDcLiSOrx9W8v2bqZ6uOA_55t/view?usp=share_link
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: Wei Chen <har...@gm...>
>
> BUG: kernel NULL pointer dereference, address: 0000000000000018
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP
> CPU: 1 PID: 7336 Comm: kworker/u4:4 Not tainted 5.15.0-rc5 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
> Workqueue: netns cleanup_net
> RIP: 0010:tipc_conn_close+0x12/0x100
con->sock is set only after tipc_topsrv_accept() is called by awork.
We should do the check under a proper lock.

Will think about it, thanks.

> Code: 02 01 e8 52 74 20 00 e9 c6 fd ff ff 66 90 66 2e 0f 1f 84 00 00
> 00 00 00 41 55 41 54 55 53 48 89 fb e8 82 4f c2 fc 48 8b 43 08 <4c> 8b
> 68 18 4d 8d a5 b0 03 00 00 4c 89 e7 e8 fb 36 44 00 f0 48 0f
> RSP: 0018:ffffc90005137d60 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff88805a9eea00 RCX: ffff88810b035280
> RDX: 0000000000000000 RSI: ffff88810b035280 RDI: 0000000000000002
> RBP: ffffc90005137db0 R08: ffffffff847b23de R09: 0000000000000001
> R10: 0000000000000005 R11: 0000000000000000 R12: ffff88810bdeed40
> R13: 000000000000027b R14: ffff88805a9eea00 R15: ffff88810ebc2058
> FS:  0000000000000000(0000) GS:ffff88813dc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000018 CR3: 000000010b0e2000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  tipc_topsrv_exit_net+0x139/0x320
>  ops_exit_list.isra.9+0x49/0x80
>  cleanup_net+0x31a/0x540
>  process_one_work+0x3fa/0x9f0
>  worker_thread+0x42/0x5c0
>  kthread+0x1a6/0x1e0
>  ret_from_fork+0x1f/0x30
> Modules linked in:
> CR2: 0000000000000018
> ---[ end trace 1524bb8c4ed3c3b4 ]---
> RIP: 0010:tipc_conn_close+0x12/0x100
> Code: 02 01 e8 52 74 20 00 e9 c6 fd ff ff 66 90 66 2e 0f 1f 84 00 00
> 00 00 00 41 55 41 54 55 53 48 89 fb e8 82 4f c2 fc 48 8b 43 08 <4c> 8b
> 68 18 4d 8d a5 b0 03 00 00 4c 89 e7 e8 fb 36 44 00 f0 48 0f
> RSP: 0018:ffffc90005137d60 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff88805a9eea00 RCX: ffff88810b035280
> RDX: 0000000000000000 RSI: ffff88810b035280 RDI: 0000000000000002
> RBP: ffffc90005137db0 R08: ffffffff847b23de R09: 0000000000000001
> R10: 0000000000000005 R11: 0000000000000000 R12: ffff88810bdeed40
> R13: 000000000000027b R14: ffff88805a9eea00 R15: ffff88810ebc2058
> FS:  0000000000000000(0000) GS:ffff88813dc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000018 CR3: 000000010b0e2000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
>    0: 02 01                add    (%rcx),%al
>    2: e8 52 74 20 00        callq  0x207459
>    7: e9 c6 fd ff ff        jmpq   0xfffffdd2
>    c: 66 90                xchg   %ax,%ax
>    e: 66 2e 0f 1f 84 00 00 nopw   %cs:0x0(%rax,%rax,1)
>   15: 00 00 00
>   18: 41 55                push   %r13
>   1a: 41 54                push   %r12
>   1c: 55                    push   %rbp
>   1d: 53                    push   %rbx
>   1e: 48 89 fb              mov    %rdi,%rbx
>   21: e8 82 4f c2 fc        callq  0xfcc24fa8
>   26: 48 8b 43 08          mov    0x8(%rbx),%rax
> * 2a: 4c 8b 68 18          mov    0x18(%rax),%r13 <-- trapping instruction
>   2e: 4d 8d a5 b0 03 00 00 lea    0x3b0(%r13),%r12
>   35: 4c 89 e7              mov    %r12,%rdi
>   38: e8 fb 36 44 00        callq  0x443738
>   3d: f0                    lock
>   3e: 48                    rex.W
>   3f: 0f                    .byte 0xf
>
> Best,
> Wei

Re: [tipc-discussion] [PATCH net] tipc: fix a null-ptr-deref in tipc_topsrv_accept

[Jon M. <jm...@re...>]

On 10/18/22 15:19, Xin Long wrote:
> syzbot found a crash in tipc_topsrv_accept:
>
>    KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
>    Workqueue: tipc_rcv tipc_topsrv_accept
>    RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
>    Call Trace:
>     <TASK>
>     tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460
>     process_one_work+0x991/0x1610 kernel/workqueue.c:2289
>     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
>     kthread+0x2e4/0x3a0 kernel/kthread.c:376
>     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
>
> It was caused by srv->listener that might be set to null by
> tipc_topsrv_stop() in net .exit whereas it's still used in
> tipc_topsrv_accept() worker.
>
> srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add
> a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to
> avoid the null-ptr-deref. To ensure the lsock is not released during the
> tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()
> where it's waiting until the tipc_topsrv_accept worker to be done.
>
> Note that sk_callback_lock is used to protect sk->sk_user_data instead of
> srv->listener, and it should check srv in tipc_topsrv_listener_data_ready()
> instead. This also ensures that no more tipc_topsrv_accept worker will be
> started after tipc_conn_close() is called in tipc_topsrv_stop() where it
> sets sk->sk_user_data to null.
>
> Fixes: 0ef897be12b8 ("tipc: separate topology server listener socket from subcsriber sockets")
> Reported-by: syz...@sy...
> Signed-off-by: Xin Long <luc...@gm...>
> ---
>   net/tipc/topsrv.c | 16 ++++++++++++----
>   1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
> index 14fd05fd6107..d92ec92f0b71 100644
> --- a/net/tipc/topsrv.c
> +++ b/net/tipc/topsrv.c
> @@ -450,12 +450,19 @@ static void tipc_conn_data_ready(struct sock *sk)
>   static void tipc_topsrv_accept(struct work_struct *work)
>   {
>   	struct tipc_topsrv *srv = container_of(work, struct tipc_topsrv, awork);
> -	struct socket *lsock = srv->listener;
> -	struct socket *newsock;
> +	struct socket *newsock, *lsock;
>   	struct tipc_conn *con;
>   	struct sock *newsk;
>   	int ret;
>   
> +	spin_lock_bh(&srv->idr_lock);
> +	if (!srv->listener) {
> +		spin_unlock_bh(&srv->idr_lock);
> +		return;
> +	}
> +	lsock = srv->listener;
> +	spin_unlock_bh(&srv->idr_lock);
> +
>   	while (1) {
>   		ret = kernel_accept(lsock, &newsock, O_NONBLOCK);
>   		if (ret < 0)
> @@ -489,7 +496,7 @@ static void tipc_topsrv_listener_data_ready(struct sock *sk)
>   
>   	read_lock_bh(&sk->sk_callback_lock);
>   	srv = sk->sk_user_data;
> -	if (srv->listener)
> +	if (srv)
>   		queue_work(srv->rcv_wq, &srv->awork);
>   	read_unlock_bh(&sk->sk_callback_lock);
>   }
> @@ -699,8 +706,9 @@ static void tipc_topsrv_stop(struct net *net)
>   	__module_get(lsock->sk->sk_prot_creator->owner);
>   	srv->listener = NULL;
>   	spin_unlock_bh(&srv->idr_lock);
> -	sock_release(lsock);
> +
>   	tipc_topsrv_work_stop(srv);
> +	sock_release(lsock);
>   	idr_destroy(&srv->conn_idr);
>   	kfree(srv);
>   }
Acked-by: Jon Maloy <jm...@re...>

[tipc-discussion] [PATCH net] tipc: fix a null-ptr-deref in tipc_topsrv_accept

[Xin L. <luc...@gm...>]

syzbot found a crash in tipc_topsrv_accept:

  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
  Workqueue: tipc_rcv tipc_topsrv_accept
  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
  Call Trace:
   <TASK>
   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460
   process_one_work+0x991/0x1610 kernel/workqueue.c:2289
   worker_thread+0x665/0x1080 kernel/workqueue.c:2436
   kthread+0x2e4/0x3a0 kernel/kthread.c:376
   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

It was caused by srv->listener that might be set to null by
tipc_topsrv_stop() in net .exit whereas it's still used in
tipc_topsrv_accept() worker.

srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add
a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to
avoid the null-ptr-deref. To ensure the lsock is not released during the
tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()
where it's waiting until the tipc_topsrv_accept worker to be done.

Note that sk_callback_lock is used to protect sk->sk_user_data instead of
srv->listener, and it should check srv in tipc_topsrv_listener_data_ready()
instead. This also ensures that no more tipc_topsrv_accept worker will be
started after tipc_conn_close() is called in tipc_topsrv_stop() where it
sets sk->sk_user_data to null.

Fixes: 0ef897be12b8 ("tipc: separate topology server listener socket from subcsriber sockets")
Reported-by: syz...@sy...
Signed-off-by: Xin Long <luc...@gm...>
---
 net/tipc/topsrv.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index 14fd05fd6107..d92ec92f0b71 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -450,12 +450,19 @@ static void tipc_conn_data_ready(struct sock *sk)
 static void tipc_topsrv_accept(struct work_struct *work)
 {
 	struct tipc_topsrv *srv = container_of(work, struct tipc_topsrv, awork);
-	struct socket *lsock = srv->listener;
-	struct socket *newsock;
+	struct socket *newsock, *lsock;
 	struct tipc_conn *con;
 	struct sock *newsk;
 	int ret;
 
+	spin_lock_bh(&srv->idr_lock);
+	if (!srv->listener) {
+		spin_unlock_bh(&srv->idr_lock);
+		return;
+	}
+	lsock = srv->listener;
+	spin_unlock_bh(&srv->idr_lock);
+
 	while (1) {
 		ret = kernel_accept(lsock, &newsock, O_NONBLOCK);
 		if (ret < 0)
@@ -489,7 +496,7 @@ static void tipc_topsrv_listener_data_ready(struct sock *sk)
 
 	read_lock_bh(&sk->sk_callback_lock);
 	srv = sk->sk_user_data;
-	if (srv->listener)
+	if (srv)
 		queue_work(srv->rcv_wq, &srv->awork);
 	read_unlock_bh(&sk->sk_callback_lock);
 }
@@ -699,8 +706,9 @@ static void tipc_topsrv_stop(struct net *net)
 	__module_get(lsock->sk->sk_prot_creator->owner);
 	srv->listener = NULL;
 	spin_unlock_bh(&srv->idr_lock);
-	sock_release(lsock);
+
 	tipc_topsrv_work_stop(srv);
+	sock_release(lsock);
 	idr_destroy(&srv->conn_idr);
 	kfree(srv);
 }
-- 
2.31.1

Re: [tipc-discussion] [PATCH] net/tipc: Remove unused struct distr_queue_item

[Jon M. <jm...@re...>]

On 9/28/22 04:56, Yuan Can wrote:
> After commit 09b5678c778f("tipc: remove dead code in tipc_net and relatives"),
> struct distr_queue_item is not used any more and can be removed as well.
>
> Signed-off-by: Yuan Can <yu...@hu...>
> ---
>   net/tipc/name_distr.c | 8 --------
>   1 file changed, 8 deletions(-)
>
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> index 8267b751a526..190b49c5cbc3 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -41,14 +41,6 @@
>   
>   int sysctl_tipc_named_timeout __read_mostly = 2000;
>   
> -struct distr_queue_item {
> -	struct distr_item i;
> -	u32 dtype;
> -	u32 node;
> -	unsigned long expires;
> -	struct list_head next;
> -};
> -
>   /**
>    * publ_to_item - add publication info to a publication message
>    * @p: publication info
Acked-by: Jon Maloy <jm...@re...>

Re: [tipc-discussion] junixsocket now supports TIPC (Java Socket API for TIPC)

[Jon M. <jm...@re...>]

On 7/2/22 14:57, Christian Kohlschütter wrote:
> Hi all,
>
> I'm the author of junixsocket, an Open-Source Java library that, until recently, focused on providing access to Unix domain sockets for Java 8 and above.
>
> It is my great delight to announce that with version 2.5, junixsocket adds support for TIPC.
>
> junixsocket enables developers to have their existing code using Socket or SocketChannel API make use of AF_TIPC sockets with very little overhead. For example, you can now run a Java web server over TIPC, in just a few lines of code.
>
> It's clear that this is just scratching the surface of what's possible. Please give junixsocket-tipc a try, let me know how it works for you, and of course, specifically, what doesn't.
>
> Lastly, let me extend my gratitude to all TIPC developers for this cool protocol.
>
> Best,
> Christian
Thank you, Christian,
This looks really cool. I hope it will have many users.

///jon

>
> junixsocket on GitHub: https://github.com/kohlschutter/junixsocket/
> junixsocket documentation: https://kohlschutter.github.io/junixsocket/
> API docs: https://kohlschutter.github.io/junixsocket/apidocs/
> TIPC specifics: https://kohlschutter.github.io/junixsocket/junixsocket-tipc/

Re: [tipc-discussion] [PATCH] tipc: fix uninit-value in tipc_nl_node_reset_link_stats

[Jon M. <jm...@re...>]

On 7/1/22 02:16, Hoang Le wrote:
> syzbot found the following issue on:
> ==================================================================
> BUG: KMSAN: uninit-value in strlen lib/string.c:495 [inline]
> BUG: KMSAN: uninit-value in strstr+0xb4/0x2e0 lib/string.c:840
>   strlen lib/string.c:495 [inline]
>   strstr+0xb4/0x2e0 lib/string.c:840
>   tipc_nl_node_reset_link_stats+0x41e/0xba0 net/tipc/node.c:2582
>   genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
>   genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
>   genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
>   netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
>   genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
>   netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
>   netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
>   netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
>   sock_sendmsg_nosec net/socket.c:714 [inline]
>   sock_sendmsg net/socket.c:734 [inline]
>   ____sys_sendmsg+0xabc/0xe90 net/socket.c:2492
>   ___sys_sendmsg+0x2a5/0x350 net/socket.c:2546
>   __sys_sendmsg net/socket.c:2575 [inline]
>   __do_sys_sendmsg net/socket.c:2584 [inline]
>   __se_sys_sendmsg net/socket.c:2582 [inline]
>   __x64_sys_sendmsg+0x367/0x540 net/socket.c:2582
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x46/0xb0
> ==================================================================
>
> This is because link name string is not validated before it's used
> in calling strstr() and strlen().
>
> Reported-by: syz...@sy...
> Signed-off-by: Hoang Le <hoa...@de...>
> ---
>   net/tipc/node.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/net/tipc/node.c b/net/tipc/node.c
> index b48d97cbbe29..23419a599471 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -2561,6 +2561,7 @@ int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info)
>   	struct net *net = sock_net(skb->sk);
>   	struct tipc_net *tn = tipc_net(net);
>   	struct tipc_link_entry *le;
> +	int len;
>   
>   	if (!info->attrs[TIPC_NLA_LINK])
>   		return -EINVAL;
> @@ -2574,7 +2575,14 @@ int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info)
>   	if (!attrs[TIPC_NLA_LINK_NAME])
>   		return -EINVAL;
>   
> +	len = nla_len(attrs[TIPC_NLA_LINK_NAME]);
> +	if (len <= 0)
> +		return -EINVAL;
> +
>   	link_name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
> +	len = min_t(int, len, TIPC_MAX_LINK_NAME);
> +	if (!memchr(link_name, '\0', len))
> +		return -EINVAL;
>   
>   	err = -EINVAL;
>   	if (!strcmp(link_name, tipc_bclink_name)) {
Acked-by: Jon Maloy <jm...@re...>

Re: [tipc-discussion] [PATCH] net: tipc: fix possible infoleak in tipc_mon_rcv()

[Jon M. <jm...@re...>]

On 6/27/22 22:59, Hangyu Hua wrote:
> dom_bef is use to cache current domain record only if current domain
> exists. But when current domain does not exist, dom_bef will still be used
> in mon_identify_lost_members. This may lead to an information leak.
>
> Fix this by adding a memset before using dom_bef.
>
> Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework")
> Signed-off-by: Hangyu Hua <hb...@gm...>
> ---
>   net/tipc/monitor.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/net/tipc/monitor.c b/net/tipc/monitor.c
> index 2f4d23238a7e..67084e5aa15c 100644
> --- a/net/tipc/monitor.c
> +++ b/net/tipc/monitor.c
> @@ -534,6 +534,7 @@ void tipc_mon_rcv(struct net *net, void *data, u16 dlen, u32 addr,
>   	state->peer_gen = new_gen;
>   
>   	/* Cache current domain record for later use */
> +	memset(&dom_bef, 0, sizeof(dom_bef));
>   	dom_bef.member_cnt = 0;
>   	dom = peer->domain;
>   	if (dom)
Acked-by: Jon Maloy <jm...@re...>

[tipc-discussion] junixsocket now supports TIPC (Java Socket API for TIPC)

[Christian K. <chr...@ko...>]

Hi all,

I'm the author of junixsocket, an Open-Source Java library that, until recently, focused on providing access to Unix domain sockets for Java 8 and above.

It is my great delight to announce that with version 2.5, junixsocket adds support for TIPC.

junixsocket enables developers to have their existing code using Socket or SocketChannel API make use of AF_TIPC sockets with very little overhead. For example, you can now run a Java web server over TIPC, in just a few lines of code.

It's clear that this is just scratching the surface of what's possible. Please give junixsocket-tipc a try, let me know how it works for you, and of course, specifically, what doesn't.

Lastly, let me extend my gratitude to all TIPC developers for this cool protocol.

Best,
Christian

junixsocket on GitHub: https://github.com/kohlschutter/junixsocket/
junixsocket documentation: https://kohlschutter.github.io/junixsocket/
API docs: https://kohlschutter.github.io/junixsocket/apidocs/
TIPC specifics: https://kohlschutter.github.io/junixsocket/junixsocket-tipc/
-- 
Dr. Christian Kohlschütter

[tipc-discussion] [PATCH] tipc: fix uninit-value in tipc_nl_node_reset_link_stats

[Hoang Le <hoa...@de...>]

syzbot found the following issue on:
==================================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:495 [inline]
BUG: KMSAN: uninit-value in strstr+0xb4/0x2e0 lib/string.c:840
 strlen lib/string.c:495 [inline]
 strstr+0xb4/0x2e0 lib/string.c:840
 tipc_nl_node_reset_link_stats+0x41e/0xba0 net/tipc/node.c:2582
 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
 genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg net/socket.c:734 [inline]
 ____sys_sendmsg+0xabc/0xe90 net/socket.c:2492
 ___sys_sendmsg+0x2a5/0x350 net/socket.c:2546
 __sys_sendmsg net/socket.c:2575 [inline]
 __do_sys_sendmsg net/socket.c:2584 [inline]
 __se_sys_sendmsg net/socket.c:2582 [inline]
 __x64_sys_sendmsg+0x367/0x540 net/socket.c:2582
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
==================================================================

This is because link name string is not validated before it's used
in calling strstr() and strlen().

Reported-by: syz...@sy...
Signed-off-by: Hoang Le <hoa...@de...>
---
 net/tipc/node.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/tipc/node.c b/net/tipc/node.c
index b48d97cbbe29..23419a599471 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -2561,6 +2561,7 @@ int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info)
 	struct net *net = sock_net(skb->sk);
 	struct tipc_net *tn = tipc_net(net);
 	struct tipc_link_entry *le;
+	int len;
 
 	if (!info->attrs[TIPC_NLA_LINK])
 		return -EINVAL;
@@ -2574,7 +2575,14 @@ int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info)
 	if (!attrs[TIPC_NLA_LINK_NAME])
 		return -EINVAL;
 
+	len = nla_len(attrs[TIPC_NLA_LINK_NAME]);
+	if (len <= 0)
+		return -EINVAL;
+
 	link_name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
+	len = min_t(int, len, TIPC_MAX_LINK_NAME);
+	if (!memchr(link_name, '\0', len))
+		return -EINVAL;
 
 	err = -EINVAL;
 	if (!strcmp(link_name, tipc_bclink_name)) {
-- 
2.30.2

[tipc-discussion] [PATCH net] tipc: move bc link creation back to tipc_node_create

[Xin L. <luc...@gm...>]

Shuang Li reported a NULL pointer dereference crash:

  [] BUG: kernel NULL pointer dereference, address: 0000000000000068
  [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
  [] Call Trace:
  []  <IRQ>
  []  tipc_bcast_rcv+0xa2/0x190 [tipc]
  []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
  []  tipc_rcv+0x3af/0x5b0 [tipc]
  []  tipc_udp_recv+0xc7/0x1e0 [tipc]

It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it
creates a node in tipc_node_check_dest(), after inserting the new node
into hashtable in tipc_node_create(), it creates the bc link. However,
there is a gap between this insert and bc link creation, a bc packet
may come in and get the node from the hashtable then try to dereference
its bc link, which is NULL.

This patch is to fix it by moving the bc link creation before inserting
into the hashtable.

Note that for a preliminary node becoming "real", the bc link creation
should also be called before it's rehashed, as we don't create it for
preliminary nodes.

Fixes: 4cbf8ac2fe5a ("tipc: enable creating a "preliminary" node")
Reported-by: Shuang Li <sh...@re...>
Signed-off-by: Xin Long <luc...@gm...>
Acked-by: Jon Maloy <jm...@re...>
---
 net/tipc/node.c | 41 ++++++++++++++++++++++-------------------
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/net/tipc/node.c b/net/tipc/node.c
index 6ef95ce565bd..b48d97cbbe29 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -472,8 +472,8 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
 				   bool preliminary)
 {
 	struct tipc_net *tn = net_generic(net, tipc_net_id);
+	struct tipc_link *l, *snd_l = tipc_bc_sndlink(net);
 	struct tipc_node *n, *temp_node;
-	struct tipc_link *l;
 	unsigned long intv;
 	int bearer_id;
 	int i;
@@ -488,6 +488,16 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
 			goto exit;
 		/* A preliminary node becomes "real" now, refresh its data */
 		tipc_node_write_lock(n);
+		if (!tipc_link_bc_create(net, tipc_own_addr(net), addr, peer_id, U16_MAX,
+					 tipc_link_min_win(snd_l), tipc_link_max_win(snd_l),
+					 n->capabilities, &n->bc_entry.inputq1,
+					 &n->bc_entry.namedq, snd_l, &n->bc_entry.link)) {
+			pr_warn("Broadcast rcv link refresh failed, no memory\n");
+			tipc_node_write_unlock_fast(n);
+			tipc_node_put(n);
+			n = NULL;
+			goto exit;
+		}
 		n->preliminary = false;
 		n->addr = addr;
 		hlist_del_rcu(&n->hash);
@@ -567,7 +577,16 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
 	n->signature = INVALID_NODE_SIG;
 	n->active_links[0] = INVALID_BEARER_ID;
 	n->active_links[1] = INVALID_BEARER_ID;
-	n->bc_entry.link = NULL;
+	if (!preliminary &&
+	    !tipc_link_bc_create(net, tipc_own_addr(net), addr, peer_id, U16_MAX,
+				 tipc_link_min_win(snd_l), tipc_link_max_win(snd_l),
+				 n->capabilities, &n->bc_entry.inputq1,
+				 &n->bc_entry.namedq, snd_l, &n->bc_entry.link)) {
+		pr_warn("Broadcast rcv link creation failed, no memory\n");
+		kfree(n);
+		n = NULL;
+		goto exit;
+	}
 	tipc_node_get(n);
 	timer_setup(&n->timer, tipc_node_timeout, 0);
 	/* Start a slow timer anyway, crypto needs it */
@@ -1155,7 +1174,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 			  bool *respond, bool *dupl_addr)
 {
 	struct tipc_node *n;
-	struct tipc_link *l, *snd_l;
+	struct tipc_link *l;
 	struct tipc_link_entry *le;
 	bool addr_match = false;
 	bool sign_match = false;
@@ -1175,22 +1194,6 @@ void tipc_node_check_dest(struct net *net, u32 addr,
 		return;
 
 	tipc_node_write_lock(n);
-	if (unlikely(!n->bc_entry.link)) {
-		snd_l = tipc_bc_sndlink(net);
-		if (!tipc_link_bc_create(net, tipc_own_addr(net),
-					 addr, peer_id, U16_MAX,
-					 tipc_link_min_win(snd_l),
-					 tipc_link_max_win(snd_l),
-					 n->capabilities,
-					 &n->bc_entry.inputq1,
-					 &n->bc_entry.namedq, snd_l,
-					 &n->bc_entry.link)) {
-			pr_warn("Broadcast rcv link creation failed, no mem\n");
-			tipc_node_write_unlock_fast(n);
-			tipc_node_put(n);
-			return;
-		}
-	}
 
 	le = &n->links[b->identity];
 
-- 
2.31.1

Re: [tipc-discussion] [PATCH net] tipc: move bc link creation back to tipc_node_create

[Jon M. <jm...@re...>]

On 6/6/22 11:24, Xin Long wrote:
> Shuang Li reported a NULL pointer dereference crash:
>
>    [] BUG: kernel NULL pointer dereference, address: 0000000000000068
>    [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
>    [] Call Trace:
>    []  <IRQ>
>    []  tipc_bcast_rcv+0xa2/0x190 [tipc]
>    []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
>    []  tipc_rcv+0x3af/0x5b0 [tipc]
>    []  tipc_udp_recv+0xc7/0x1e0 [tipc]
>
> It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it
> creates a node in tipc_node_check_dest(), after inserting the new node
> into hashtable in tipc_node_create(), it creates the bc link. However,
> there is a gap between this insert and bc link creation, a bc packet
> may come in and get the node from the hashtable then try to dereference
> its bc link, which is NULL.
>
> This patch is to fix it by moving the bc link creation before inserting
> into the hashtable.
>
> Note that for a preliminary node becoming "real", the bc link creation
> should also be called before it's rehashed, as we don't create it for
> preliminary nodes.
>
> Fixes: 4cbf8ac2fe5a ("tipc: enable creating a "preliminary" node")
> Reported-by: Shuang Li <sh...@re...>
> Signed-off-by: Xin Long <luc...@gm...>
> ---
>   net/tipc/node.c | 41 ++++++++++++++++++++++-------------------
>   1 file changed, 22 insertions(+), 19 deletions(-)
>
> diff --git a/net/tipc/node.c b/net/tipc/node.c
> index 6ef95ce565bd..b48d97cbbe29 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -472,8 +472,8 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
>   				   bool preliminary)
>   {
>   	struct tipc_net *tn = net_generic(net, tipc_net_id);
> +	struct tipc_link *l, *snd_l = tipc_bc_sndlink(net);
>   	struct tipc_node *n, *temp_node;
> -	struct tipc_link *l;
>   	unsigned long intv;
>   	int bearer_id;
>   	int i;
> @@ -488,6 +488,16 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
>   			goto exit;
>   		/* A preliminary node becomes "real" now, refresh its data */
>   		tipc_node_write_lock(n);
> +		if (!tipc_link_bc_create(net, tipc_own_addr(net), addr, peer_id, U16_MAX,
> +					 tipc_link_min_win(snd_l), tipc_link_max_win(snd_l),
> +					 n->capabilities, &n->bc_entry.inputq1,
> +					 &n->bc_entry.namedq, snd_l, &n->bc_entry.link)) {
> +			pr_warn("Broadcast rcv link refresh failed, no memory\n");
> +			tipc_node_write_unlock_fast(n);
> +			tipc_node_put(n);
> +			n = NULL;
> +			goto exit;
> +		}
>   		n->preliminary = false;
>   		n->addr = addr;
>   		hlist_del_rcu(&n->hash);
> @@ -567,7 +577,16 @@ struct tipc_node *tipc_node_create(struct net *net, u32 addr, u8 *peer_id,
>   	n->signature = INVALID_NODE_SIG;
>   	n->active_links[0] = INVALID_BEARER_ID;
>   	n->active_links[1] = INVALID_BEARER_ID;
> -	n->bc_entry.link = NULL;
> +	if (!preliminary &&
> +	    !tipc_link_bc_create(net, tipc_own_addr(net), addr, peer_id, U16_MAX,
> +				 tipc_link_min_win(snd_l), tipc_link_max_win(snd_l),
> +				 n->capabilities, &n->bc_entry.inputq1,
> +				 &n->bc_entry.namedq, snd_l, &n->bc_entry.link)) {
> +		pr_warn("Broadcast rcv link creation failed, no memory\n");
> +		kfree(n);
> +		n = NULL;
> +		goto exit;
> +	}
>   	tipc_node_get(n);
>   	timer_setup(&n->timer, tipc_node_timeout, 0);
>   	/* Start a slow timer anyway, crypto needs it */
> @@ -1155,7 +1174,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   			  bool *respond, bool *dupl_addr)
>   {
>   	struct tipc_node *n;
> -	struct tipc_link *l, *snd_l;
> +	struct tipc_link *l;
>   	struct tipc_link_entry *le;
>   	bool addr_match = false;
>   	bool sign_match = false;
> @@ -1175,22 +1194,6 @@ void tipc_node_check_dest(struct net *net, u32 addr,
>   		return;
>   
>   	tipc_node_write_lock(n);
> -	if (unlikely(!n->bc_entry.link)) {
> -		snd_l = tipc_bc_sndlink(net);
> -		if (!tipc_link_bc_create(net, tipc_own_addr(net),
> -					 addr, peer_id, U16_MAX,
> -					 tipc_link_min_win(snd_l),
> -					 tipc_link_max_win(snd_l),
> -					 n->capabilities,
> -					 &n->bc_entry.inputq1,
> -					 &n->bc_entry.namedq, snd_l,
> -					 &n->bc_entry.link)) {
> -			pr_warn("Broadcast rcv link creation failed, no mem\n");
> -			tipc_node_write_unlock_fast(n);
> -			tipc_node_put(n);
> -			return;
> -		}
> -	}
>   
>   	le = &n->links[b->identity];
>   
Acked-by: Jon Maloy <jm...@re...>

[tipc-discussion] [net-next] tipc: cleanup unused function

[Hoang Le <hoa...@de...>]

tipc_dest_list_len() is not being called anywhere. Clean it up.

Acked-by: Jon Maloy <jm...@re...>
Signed-off-by: Hoang Le <hoa...@de...>
---
 net/tipc/name_table.c | 11 -----------
 net/tipc/name_table.h |  1 -
 2 files changed, 12 deletions(-)

diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 1d8ba233d047..d1180370fdf4 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -1202,14 +1202,3 @@ void tipc_dest_list_purge(struct list_head *l)
 		kfree(dst);
 	}
 }
-
-int tipc_dest_list_len(struct list_head *l)
-{
-	struct tipc_dest *dst;
-	int i = 0;
-
-	list_for_each_entry(dst, l, list) {
-		i++;
-	}
-	return i;
-}
diff --git a/net/tipc/name_table.h b/net/tipc/name_table.h
index 259f95e3d99c..3bcd9ef8cee3 100644
--- a/net/tipc/name_table.h
+++ b/net/tipc/name_table.h
@@ -151,6 +151,5 @@ bool tipc_dest_push(struct list_head *l, u32 node, u32 port);
 bool tipc_dest_pop(struct list_head *l, u32 *node, u32 *port);
 bool tipc_dest_del(struct list_head *l, u32 node, u32 port);
 void tipc_dest_list_purge(struct list_head *l);
-int tipc_dest_list_len(struct list_head *l);
 
 #endif
-- 
2.30.2