All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: bestswngs@gmail.com
Cc: Simon Horman <horms@kernel.org>,
	jmaloy@redhat.com, netdev@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	hoang.h.le@dektech.com.au, xmei5@asu.edu,
	linux-kernel@vger.kernel.org, tung.quang.nguyen@est.tech
Subject: Re: [PATCH net v2] tipc: fix NULL deref in tipc_named_node_up() on empty publication list
Date: Mon, 13 Jul 2026 14:35:00 +0100	[thread overview]
Message-ID: <20260713133459.1777719-2-horms@kernel.org> (raw)
In-Reply-To: <20260706163024.1205930-2-bestswngs@gmail.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
tipc: fix NULL deref in tipc_named_node_up() on empty publication list

This commit fixes a NULL pointer dereference in tipc_named_node_up() that
occurs when the cluster_scope publication list is empty. The fix introduces
an early return to avoid calling named_distribute() with an empty list.

> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> index ba4f4906e13b7..60ccaa862162c 100644
> --- a/net/tipc/name_distr.c
> +++ b/net/tipc/name_distr.c
> @@ -218,6 +218,10 @@ void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)
>  	spin_unlock_bh(&tn->nametbl_lock);
>  
>  	read_lock_bh(&nt->cluster_scope_lock);
> +	if (list_empty(&nt->cluster_scope)) {
> +		read_unlock_bh(&nt->cluster_scope_lock);
> +		return;
> +	}

[Severity: Critical]
Does this early return prevent the transmission of the last_bulk
synchronization message to the peer node?

In tipc_named_dequeue(), the peer node sets *open = true only when receiving
a message where msg_is_last_bulk(hdr) is true:

net/tipc/name_distr.c:tipc_named_dequeue() {
        ...
        if (*open && (*rcv_nxt == seqno)) {
                (*rcv_nxt)++;
                __skb_unlink(skb, namedq);
                ...
                return skb;
        }
        ...
}

If *open is false, all subsequent non-bulk name publications will fail this
sequence check and remain in the namedq indefinitely. 

Without sending the last_bulk message, could this cause a permanent stall
of name table updates and an unbounded memory leak of socket buffers on the
peer node?

>  	named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);

[Severity: High]
This isn't a bug introduced by this patch, but looking at named_distribute()
called here, what happens if buffer allocation fails during the loop?

Inside named_distribute():

net/tipc/name_distr.c:named_distribute() {
        ...
        if (!skb) {
                skb = named_prepare_buf(net, PUBLICATION, msg_rem, dnode);
                if (!skb) {
                        pr_warn("Bulk publication failure\n");
                        return;
                }
        ...
}

If the function returns early due to allocation failure, the messages
already added to the queue are transmitted by tipc_node_xmit(), but none
of them will have the last_bulk flag set since that happens at the very end
of the function.

Could this also prevent the receiving node from transitioning its named_open
state to true, leading to the exact same permanent stall and memory leak of
subsequent normal name publications?

>  	tipc_node_xmit(net, &head, dnode, 0);
>  	read_unlock_bh(&nt->cluster_scope_lock);

  reply	other threads:[~2026-07-13 13:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 16:30 [PATCH net v2] tipc: fix NULL deref in tipc_named_node_up() on empty publication list Weiming Shi
2026-07-13 13:35 ` Simon Horman [this message]
2026-07-13 13:46 ` Simon Horman
2026-07-14 17:43   ` Weiming Shi

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=20260713133459.1777719-2-horms@kernel.org \
    --to=horms@kernel.org \
    --cc=bestswngs@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hoang.h.le@dektech.com.au \
    --cc=jmaloy@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=tung.quang.nguyen@est.tech \
    --cc=xmei5@asu.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.