AI Trajectory


Trajectory: (Expand/Collapse All)
Seq Timestamp Type Name Duration
0/0 2026/07/07 00:40 flow patch-triage
1m Args:
null

Results:
{
  "EnableConfigs": [
    "TIPC",
    "TIPC_MEDIA_UDP"
  ],
  "FocusSymbols": [
    "tipc_named_node_up",
    "named_distribute"
  ],
  "Reasoning": "The patch fixes a potential null-pointer dereference in `named_distribute` (called by `tipc_named_node_up`) that occurs when `nt-\u003ecluster_scope` is empty during TIPC node discovery. Fuzzing should focus on TIPC node connection and publication distribution to ensure the empty list case is properly handled.",
  "WorthFuzzing": true
}

1/1 2026/07/07 00:40 action read-patch-diff
0m Args:
null

Results:
{
  "PatchDiff": "commit 717541061a747d8e29f0a66361328d335f5583d5\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jul 7 00:40:21 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c\nindex ba4f4906e13b70..60ccaa862162ca 100644\n--- a/net/tipc/name_distr.c\n+++ b/net/tipc/name_distr.c\n@@ -218,6 +218,10 @@ void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)\n \tspin_unlock_bh(\u0026tn-\u003enametbl_lock);\n \n \tread_lock_bh(\u0026nt-\u003ecluster_scope_lock);\n+\tif (list_empty(\u0026nt-\u003ecluster_scope)) {\n+\t\tread_unlock_bh(\u0026nt-\u003ecluster_scope_lock);\n+\t\treturn;\n+\t}\n \tnamed_distribute(net, \u0026head, dnode, \u0026nt-\u003ecluster_scope, seqno);\n \ttipc_node_xmit(net, \u0026head, dnode, 0);\n \tread_unlock_bh(\u0026nt-\u003ecluster_scope_lock);\n"
}

2/1 2026/07/07 00:40 agent patch-evaluator
1m Model:
gemini-3.1-pro-preview

Args:
null

Results:
{
  "EnableConfigs": [
    "TIPC",
    "TIPC_MEDIA_UDP"
  ],
  "FocusSymbols": [
    "tipc_named_node_up",
    "named_distribute"
  ],
  "Reasoning": "The patch fixes a potential null-pointer dereference in `named_distribute` (called by `tipc_named_node_up`) that occurs when `nt-\u003ecluster_scope` is empty during TIPC node discovery. Fuzzing should focus on TIPC node connection and publication distribution to ensure the empty list case is properly handled.",
  "WorthFuzzing": true
}

Instruction:
You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Prompt:
For your convenience, here is the diff of the changes:
commit 717541061a747d8e29f0a66361328d335f5583d5
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jul 7 00:40:21 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index ba4f4906e13b70..60ccaa862162ca 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;
+	}
 	named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
 	tipc_node_xmit(net, &head, dnode, 0);
 	read_unlock_bh(&nt->cluster_scope_lock);

3/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 1906
							output: 39
							thoughts: 94
						

Thoughts:
Here's my analysis of the situation:

**Investigating a TIPC Naming Issue**

Okay, so I'm looking at a patch within `net/tipc/name_distr.c`. Specifically, there's a new check added in the `tipc_named_node_up` function. It seems they've inserted an `if (list_empty(&nt->cluster_scope))` condition. Basically, if the `cluster_scope` list associated with the named node (`nt`) is empty, the code now unlocks and exits the function early.

My initial thought is to figure out *why* this check was deemed necessary. Empty `cluster_scope` lists in this context are a bit unusual, so I need to understand the logic behind this early exit. What's the potential implication of *not* running the rest of `tipc_named_node_up` when this list is empty? Is it a performance optimization? A bug fix to prevent some unexpected behavior with an empty list? Or is it related to handling a specific edge case in the network topology or naming configuration?

To get a clearer picture, I'm going to jump into `net/tipc/name_distr.c` right away. I need to understand the surrounding code, the data structures involved, and the overall purpose of `tipc_named_node_up`. Seeing the call graph and the surrounding logic is going to be crucial to determining whether this patch is sound and necessary, or if there is a potential for introducing new problems. I'll be looking for clues about the expected state of `cluster_scope` and the actions triggered in the event of `node_up` state.



4/2 2026/07/07 00:40 tool grepper
0m Args:
{
  "Expression": "tipc_named_node_up",
  "PathPrefix": "net/tipc/name_distr.c"
}

Results:
{
  "Output": "net/tipc/name_distr.c=150=static void named_distribute(struct net *net, struct sk_buff_head *list,\n--\nnet/tipc/name_distr.c-200-/**\nnet/tipc/name_distr.c:201: * tipc_named_node_up - tell specified node about all publications by this node\nnet/tipc/name_distr.c-202- * @net: the associated network namespace\n--\nnet/tipc/name_distr.c-205- */\nnet/tipc/name_distr.c:206:void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)\nnet/tipc/name_distr.c-207-{\n"
}

5/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 2607
							output: 30
							thoughts: 27
						

Thoughts:
Here's a summary of my thought process:

**Diving into `tipc_named_node_up` and TIPC Configuration**

Okay, so the `tipc_named_node_up` function has been touched. My immediate thought is, "Alright, let's see what's changed and how that might impact the overall TIPC (Transparent Inter-Process Communication) behavior." Given my expertise, I'm already formulating hypotheses about potential areas of impact – maybe node naming, network events, or even error handling.

The first thing I need to do is quickly identify the configuration that actually enables TIPC. I'm going to need to track down the relevant kernel config options and dependencies; I'll want to review the Kconfig files related to TIPC to pinpoint the relevant settings, such as `CONFIG_TIPC` or similar. I'll need to know which flags are enabled to understand if the change to `tipc_named_node_up` is even relevant in the current build environment. I need to establish a base context before digging deeper into the code. Time to get to work.



6/2 2026/07/07 00:40 tool grepper
0m Args:
{
  "Expression": "config TIPC",
  "PathPrefix": "net/tipc/Kconfig"
}

Results:
{
  "Output": "net/tipc/Kconfig-5-\nnet/tipc/Kconfig:6:menuconfig TIPC\nnet/tipc/Kconfig-7-\ttristate \"The TIPC Protocol\"\n--\nnet/tipc/Kconfig-23-\nnet/tipc/Kconfig:24:config TIPC_MEDIA_IB\nnet/tipc/Kconfig-25-\tbool \"InfiniBand media type support\"\n--\nnet/tipc/Kconfig-29-\t  IP-over-InfiniBand devices.\nnet/tipc/Kconfig:30:config TIPC_MEDIA_UDP\nnet/tipc/Kconfig-31-\tbool \"IP/UDP media type support\"\n--\nnet/tipc/Kconfig-37-\nnet/tipc/Kconfig:38:config TIPC_CRYPTO\nnet/tipc/Kconfig-39-\tbool \"TIPC encryption support\"\n--\nnet/tipc/Kconfig-52-\nnet/tipc/Kconfig:53:config TIPC_DIAG\nnet/tipc/Kconfig-54-\ttristate \"TIPC: socket monitoring interface\"\n"
}

7/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 3187
							output: 39
							thoughts: 181
						

Thoughts:
**Analyzing a TIPC Configuration Change**

Okay, so the configuration I'm looking at is definitely using TIPC. The patch introduces an early return within `tipc_named_node_up` when `nt->cluster_scope` is empty. My initial thought is that this avoids potential issues down the line. It's probably preventing calls to `named_distribute` and `tipc_node_xmit` when they're given an empty list, `nt->cluster_scope`.

Is it strictly a bug fix, or is it an optimization? Does `named_distribute` handle empty lists gracefully? Perhaps it's harmless to call with an empty list, but better to avoid the overhead. Hmmm, now I'm thinking... `named_distribute` takes `&head` and `&nt->cluster_scope`. So if `nt->cluster_scope` is empty, maybe `named_distribute` *does* nothing, and it's redundant to call. But... what about `tipc_node_xmit`? It's possible that the empty list *there* could cause a problem, like an attempt to send an empty message. Or maybe it's still just an optimization. I'm going to quickly check the `named_distribute` function in `net/tipc/name_distr.c` to be sure. It's the most likely source of the problem.



8/2 2026/07/07 00:40 tool read-file
0m Args:
{
  "File": "net/tipc/name_distr.c",
  "FirstLine": 150,
  "LineCount": 50
}

Results:
{
  "Contents": " 150:\tstatic void named_distribute(struct net *net, struct sk_buff_head *list,\n 151:\t\t\t\t     u32 dnode, struct list_head *pls, u16 seqno)\n 152:\t{\n 153:\t\tstruct publication *publ;\n 154:\t\tstruct sk_buff *skb = NULL;\n 155:\t\tstruct distr_item *item = NULL;\n 156:\t\tu32 msg_dsz = ((tipc_node_get_mtu(net, dnode, 0, false) - INT_H_SIZE) /\n 157:\t\t\t\tITEM_SIZE) * ITEM_SIZE;\n 158:\t\tu32 msg_rem = msg_dsz;\n 159:\t\tstruct tipc_msg *hdr;\n 160:\t\n 161:\t\tlist_for_each_entry(publ, pls, binding_node) {\n 162:\t\t\t/* Prepare next buffer: */\n 163:\t\t\tif (!skb) {\n 164:\t\t\t\tskb = named_prepare_buf(net, PUBLICATION, msg_rem,\n 165:\t\t\t\t\t\t\tdnode);\n 166:\t\t\t\tif (!skb) {\n 167:\t\t\t\t\tpr_warn(\"Bulk publication failure\\n\");\n 168:\t\t\t\t\treturn;\n 169:\t\t\t\t}\n 170:\t\t\t\thdr = buf_msg(skb);\n 171:\t\t\t\tmsg_set_bc_ack_invalid(hdr, true);\n 172:\t\t\t\tmsg_set_bulk(hdr);\n 173:\t\t\t\tmsg_set_non_legacy(hdr);\n 174:\t\t\t\titem = (struct distr_item *)msg_data(hdr);\n 175:\t\t\t}\n 176:\t\n 177:\t\t\t/* Pack publication into message: */\n 178:\t\t\tpubl_to_item(item, publ);\n 179:\t\t\titem++;\n 180:\t\t\tmsg_rem -= ITEM_SIZE;\n 181:\t\n 182:\t\t\t/* Append full buffer to list: */\n 183:\t\t\tif (!msg_rem) {\n 184:\t\t\t\t__skb_queue_tail(list, skb);\n 185:\t\t\t\tskb = NULL;\n 186:\t\t\t\tmsg_rem = msg_dsz;\n 187:\t\t\t}\n 188:\t\t}\n 189:\t\tif (skb) {\n 190:\t\t\thdr = buf_msg(skb);\n 191:\t\t\tmsg_set_size(hdr, INT_H_SIZE + (msg_dsz - msg_rem));\n 192:\t\t\tskb_trim(skb, INT_H_SIZE + (msg_dsz - msg_rem));\n 193:\t\t\t__skb_queue_tail(list, skb);\n 194:\t\t}\n 195:\t\thdr = buf_msg(skb_peek_tail(list));\n 196:\t\tmsg_set_last_bulk(hdr);\n 197:\t\tmsg_set_named_seqno(hdr, seqno);\n 198:\t}\n 199:\t\n"
}

9/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 4524
							output: 29
							thoughts: 153
						

Thoughts:
**Debugging a Null Pointer Dereference**

Okay, so I'm looking at this `named_distribute` function, and I'm seeing a potential problem. If `pls`, which is a pointer to the cluster scope, is empty, that means the `list_for_each_entry` loop won't execute. Consequently, `skb` remains `NULL`. Then, the crucial conditional `if (skb)` will evaluate to false. So far, so good, but then it proceeds to `hdr = buf_msg(skb_peek_tail(list));`. Now, if the list is actually empty, then `skb_peek_tail(list)` is going to return `NULL`. This means that we're going to feed `buf_msg(NULL)` and that is very, very likely to crash. Hold on a second, though, let me double-check. I'm pretty sure `buf_msg` is defined as something along the lines of `(struct tipc_msg *)skb->data`, which means we are using NULL for the pointer! I need to go and confirm how `buf_msg` is being used and defined.



10/2 2026/07/07 00:40 tool grepper
0m Error:
no matches

Args:
{
  "Expression": "define buf_msg",
  "PathPrefix": "net/tipc/"
}

Results:
{
  "error": "no matches"
}

11/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 4969
							output: 28
							thoughts: 13
						

Thoughts:
Here's a summary of my thought process:

**Diving into `buf_msg`**

Okay, so I'm looking at this code and the first thing that jumps out is `buf_msg`. My instincts tell me it's likely a function, but I need to be absolutely sure. Given my experience, I'm already formulating hypotheses about its role – maybe it's a message buffer handling function, or potentially a utility for formatting data. It could also be related to specific networking or data serialization operations, or perhaps it has a connection to file i/o. I’m already mentally sketching out its potential signature – what kind of arguments is it likely to take? What could be the return value? My expert intuition kicks in, and I start thinking about the potential implications if this function is behaving abnormally. I want to fully understand its function before I move on.



12/2 2026/07/07 00:40 tool grepper
0m Args:
{
  "Expression": "buf_msg",
  "PathPrefix": "net/tipc/"
}

Results:
{
  "Output": "\nFull output is too long, showing 500 out of 705 lines.\nUse more precise expression if possible.\n\nnet/tipc/bcast.c=288=static int tipc_rcast_xmit(struct net *net, struct sk_buff_head *pkts,\n--\nnet/tipc/bcast.c-294-\nnet/tipc/bcast.c:295:\tselector = msg_link_selector(buf_msg(skb_peek(pkts)));\nnet/tipc/bcast.c-296-\t__skb_queue_head_init(\u0026_pkts);\n--\nnet/tipc/bcast.c=317=static int tipc_mcast_send_sync(struct net *net, struct sk_buff *skb,\n--\nnet/tipc/bcast.c-330-\nnet/tipc/bcast.c:331:\thdr = buf_msg(skb);\nnet/tipc/bcast.c-332-\tif (msg_user(hdr) == MSG_FRAGMENTER)\n--\nnet/tipc/bcast.c-349-\t/* Reverse method for dummy message */\nnet/tipc/bcast.c:350:\t_hdr = buf_msg(_skb);\nnet/tipc/bcast.c-351-\tmsg_set_size(_hdr, MCAST_H_SIZE);\n--\nnet/tipc/bcast.c=378=int tipc_mcast_xmit(struct net *net, struct sk_buff_head *pkts,\n--\nnet/tipc/bcast.c-400-\t\tskb = skb_peek(pkts);\nnet/tipc/bcast.c:401:\t\thdr = buf_msg(skb);\nnet/tipc/bcast.c-402-\t\tif (msg_user(hdr) == MSG_FRAGMENTER)\n--\nnet/tipc/bcast.c=436=int tipc_bcast_rcv(struct net *net, struct tipc_link *l, struct sk_buff *skb)\nnet/tipc/bcast.c-437-{\nnet/tipc/bcast.c:438:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/bcast.c-439-\tstruct sk_buff_head *inputq = \u0026tipc_bc_base(net)-\u003einputq;\n--\nnet/tipc/bcast.c=790=void tipc_mcast_filter_msg(struct net *net, struct sk_buff_head *defq,\n--\nnet/tipc/bcast.c-801-\nnet/tipc/bcast.c:802:\thdr = buf_msg(skb);\nnet/tipc/bcast.c-803-\n--\nnet/tipc/bcast.c-814-\tskb_queue_walk(defq, _skb) {\nnet/tipc/bcast.c:815:\t\t_hdr = buf_msg(_skb);\nnet/tipc/bcast.c-816-\t\tif (msg_orignode(_hdr) != node)\n--\nnet/tipc/bcast.c-859-\tskb_queue_walk_safe(defq, _skb, tmp) {\nnet/tipc/bcast.c:860:\t\t_hdr = buf_msg(_skb);\nnet/tipc/bcast.c-861-\t\tif (msg_orignode(_hdr) != node)\n--\nnet/tipc/bearer.c=562=void tipc_bearer_xmit_skb(struct net *net, u32 bearer_id,\n--\nnet/tipc/bearer.c-565-{\nnet/tipc/bearer.c:566:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/bearer.c-567-\tstruct tipc_bearer *b;\n--\nnet/tipc/bearer.c=585=void tipc_bearer_xmit(struct net *net, u32 bearer_id,\n--\nnet/tipc/bearer.c-601-\t\t__skb_dequeue(xmitq);\nnet/tipc/bearer.c:602:\t\tif (likely(test_bit(0, \u0026b-\u003eup) || msg_is_reset(buf_msg(skb)))) {\nnet/tipc/bearer.c-603-#ifdef CONFIG_TIPC_CRYPTO\n--\nnet/tipc/bearer.c=617=void tipc_bearer_bc_xmit(struct net *net, u32 bearer_id,\n--\nnet/tipc/bearer.c-631-\tskb_queue_walk_safe(xmitq, skb, tmp) {\nnet/tipc/bearer.c:632:\t\thdr = buf_msg(skb);\nnet/tipc/bearer.c-633-\t\tmsg_set_non_seq(hdr, 1);\n--\nnet/tipc/crypto.c=1039=static int tipc_ehdr_build(struct net *net, struct tipc_aead *aead,\n--\nnet/tipc/crypto.c-1042-{\nnet/tipc/crypto.c:1043:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/crypto.c-1044-\tstruct tipc_ehdr *ehdr;\n--\nnet/tipc/crypto.c=1390=static void tipc_crypto_key_synch(struct tipc_crypto *rx, struct sk_buff *skb)\n--\nnet/tipc/crypto.c-1393-\tstruct tipc_crypto *tx = tipc_net(rx-\u003enet)-\u003ecrypto_tx;\nnet/tipc/crypto.c:1394:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/crypto.c-1395-\tu32 self = tipc_own_addr(rx-\u003enet);\n--\nnet/tipc/crypto.c=1689=int tipc_crypto_xmit(struct net *net, struct sk_buff **skb,\n--\nnet/tipc/crypto.c-1695-\tstruct tipc_crypto_stats __percpu *stats = tx-\u003estats;\nnet/tipc/crypto.c:1696:\tstruct tipc_msg *hdr = buf_msg(*skb);\nnet/tipc/crypto.c-1697-\tstruct tipc_key key = tx-\u003ekey;\n--\nnet/tipc/crypto.c=2164=void tipc_crypto_msg_rcv(struct net *net, struct sk_buff *skb)\n--\nnet/tipc/crypto.c-2171-\nnet/tipc/crypto.c:2172:\thdr = buf_msg(skb);\nnet/tipc/crypto.c-2173-\trx = tipc_node_crypto_rx_by_addr(net, msg_prevnode(hdr));\n--\nnet/tipc/crypto.c=2238=static int tipc_crypto_key_xmit(struct net *net, struct tipc_aead_key *skey,\n--\nnet/tipc/crypto.c-2252-\nnet/tipc/crypto.c:2253:\thdr = buf_msg(skb);\nnet/tipc/crypto.c-2254-\ttipc_msg_init(tipc_own_addr(net), hdr, MSG_CRYPTO, KEY_DISTR_MSG,\n--\nnet/tipc/discover.c=83=static void tipc_disc_init_msg(struct net *net, struct sk_buff *skb,\n--\nnet/tipc/discover.c-89-\nnet/tipc/discover.c:90:\thdr = buf_msg(skb);\nnet/tipc/discover.c-91-\ttipc_msg_init(tn-\u003etrial_addr, hdr, LINK_CONFIG, mtyp,\n--\nnet/tipc/discover.c=104=static void tipc_disc_msg_xmit(struct net *net, u32 mtyp, u32 dst,\n--\nnet/tipc/discover.c-114-\t\treturn;\nnet/tipc/discover.c:115:\thdr = buf_msg(skb);\nnet/tipc/discover.c-116-\ttipc_disc_init_msg(net, skb, mtyp, b);\n--\nnet/tipc/discover.c=143=static bool tipc_disc_addr_trial_msg(struct tipc_discoverer *d,\n--\nnet/tipc/discover.c-165-\t\ttn-\u003etrial_addr = sugg_addr;\nnet/tipc/discover.c:166:\t\tmsg_set_prevnode(buf_msg(d-\u003eskb), sugg_addr);\nnet/tipc/discover.c-167-\t\ttn-\u003eaddr_trial_end = jiffies + msecs_to_jiffies(1000);\n--\nnet/tipc/discover.c-173-\t\tschedule_work(\u0026tn-\u003ework);\nnet/tipc/discover.c:174:\t\tmsg_set_prevnode(buf_msg(d-\u003eskb), tn-\u003etrial_addr);\nnet/tipc/discover.c:175:\t\tmsg_set_type(buf_msg(d-\u003eskb), DSC_REQ_MSG);\nnet/tipc/discover.c-176-\t}\n--\nnet/tipc/discover.c=195=void tipc_disc_rcv(struct net *net, struct sk_buff *skb,\n--\nnet/tipc/discover.c-198-\tstruct tipc_net *tn = tipc_net(net);\nnet/tipc/discover.c:199:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/discover.c-200-\tu32 pnet_hash = msg_peer_net_hash(hdr);\n--\nnet/tipc/discover.c-219-\t}\nnet/tipc/discover.c:220:\thdr = buf_msg(skb);\nnet/tipc/discover.c-221-\n--\nnet/tipc/discover.c=295=static void tipc_disc_timeout(struct timer_list *t)\n--\nnet/tipc/discover.c-328-\t\t\td-\u003etimer_intv = TIPC_DISC_FAST;\nnet/tipc/discover.c:329:\t\tmsg_set_type(buf_msg(d-\u003eskb), DSC_REQ_MSG);\nnet/tipc/discover.c:330:\t\tmsg_set_prevnode(buf_msg(d-\u003eskb), tn-\u003etrial_addr);\nnet/tipc/discover.c-331-\t}\n--\nnet/tipc/discover.c=352=int tipc_disc_create(struct net *net, struct tipc_bearer *b,\n--\nnet/tipc/discover.c-370-\t\ttn-\u003eaddr_trial_end = jiffies + msecs_to_jiffies(1000);\nnet/tipc/discover.c:371:\t\tmsg_set_type(buf_msg(d-\u003eskb), DSC_TRIAL_MSG);\nnet/tipc/discover.c-372-\t}\n--\nnet/tipc/group.c=472=static void tipc_group_sort_msg(struct sk_buff *skb, struct sk_buff_head *defq)\nnet/tipc/group.c-473-{\nnet/tipc/group.c:474:\tstruct tipc_msg *_hdr, *hdr = buf_msg(skb);\nnet/tipc/group.c-475-\tu16 bc_seqno = msg_grp_bc_seqno(hdr);\n--\nnet/tipc/group.c-481-\t\tskb_queue_walk_safe(defq, _skb, tmp) {\nnet/tipc/group.c:482:\t\t\t_hdr = buf_msg(_skb);\nnet/tipc/group.c-483-\t\t\tif (!less(bc_seqno, msg_grp_bc_seqno(_hdr)))\n--\nnet/tipc/group.c=496=void tipc_group_filter_msg(struct tipc_group *grp, struct sk_buff_head *inputq,\n--\nnet/tipc/group.c-509-\nnet/tipc/group.c:510:\thdr = buf_msg(skb);\nnet/tipc/group.c-511-\tnode =  msg_orignode(hdr);\n--\nnet/tipc/group.c-528-\twhile ((skb = skb_peek(defq))) {\nnet/tipc/group.c:529:\t\thdr = buf_msg(skb);\nnet/tipc/group.c-530-\t\tmtyp = msg_type(hdr);\n--\nnet/tipc/group.c=668=static void tipc_group_create_event(struct tipc_group *grp,\n--\nnet/tipc/group.c-692-\nnet/tipc/group.c:693:\thdr = buf_msg(skb);\nnet/tipc/group.c-694-\tmsg_set_nametype(hdr, grp-\u003etype);\n--\nnet/tipc/group.c=703=static void tipc_group_proto_xmit(struct tipc_group *grp, struct tipc_member *m,\n--\nnet/tipc/group.c-720-\nnet/tipc/group.c:721:\thdr = buf_msg(skb);\nnet/tipc/group.c-722-\n--\nnet/tipc/link.c=763=static void link_profile_stats(struct tipc_link *l)\n--\nnet/tipc/link.c-775-\t\treturn;\nnet/tipc/link.c:776:\tmsg = buf_msg(skb);\nnet/tipc/link.c-777-\tlength = msg_size(msg);\n--\nnet/tipc/link.c=881=static int link_schedule_user(struct tipc_link *l, struct tipc_msg *hdr)\n--\nnet/tipc/link.c-891-\t\treturn -ENOBUFS;\nnet/tipc/link.c:892:\tmsg_set_dest_droppable(buf_msg(skb), true);\nnet/tipc/link.c-893-\tTIPC_SKB_CB(skb)-\u003echain_imp = msg_importance(hdr);\n--\nnet/tipc/link.c=1011=int tipc_link_xmit(struct tipc_link *l, struct sk_buff_head *list,\n--\nnet/tipc/link.c-1031-\nnet/tipc/link.c:1032:\thdr = buf_msg(skb_peek(list));\nnet/tipc/link.c-1033-\tif (unlikely(msg_size(hdr) \u003e mtu)) {\n--\nnet/tipc/link.c-1059-\t\tif (likely(skb_queue_len(transmq) \u003c cwin)) {\nnet/tipc/link.c:1060:\t\t\thdr = buf_msg(skb);\nnet/tipc/link.c-1061-\t\t\tmsg_set_seqno(hdr, seqno);\n--\nnet/tipc/link.c=1146=static void tipc_link_advance_backlog(struct tipc_link *l,\n--\nnet/tipc/link.c-1165-\t\t__skb_dequeue(\u0026l-\u003ebacklogq);\nnet/tipc/link.c:1166:\t\thdr = buf_msg(skb);\nnet/tipc/link.c-1167-\t\timp = msg_importance(hdr);\n--\nnet/tipc/link.c=1195=static bool link_retransmit_failure(struct tipc_link *l, struct tipc_link *r,\n--\nnet/tipc/link.c-1210-\nnet/tipc/link.c:1211:\thdr = buf_msg(skb);\nnet/tipc/link.c-1212-\tif (link_is_bc_sndlink(l) \u0026\u0026 !less(r-\u003eacked, msg_seqno(hdr)))\n--\nnet/tipc/link.c=1244=static bool tipc_data_input(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-1247-\tstruct sk_buff_head *mc_inputq = l-\u003ebc_rcvlink-\u003einputq;\nnet/tipc/link.c:1248:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-1249-\n--\nnet/tipc/link.c=1295=static int tipc_link_input(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-1298-{\nnet/tipc/link.c:1299:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-1300-\tstruct sk_buff *iskb;\n--\nnet/tipc/link.c=1340=static int tipc_link_tnl_rcv(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-1345-\tstruct sk_buff_head *fdefq = \u0026l-\u003efailover_deferdq;\nnet/tipc/link.c:1346:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-1347-\tstruct sk_buff *iskb;\n--\nnet/tipc/link.c=1532=static int tipc_link_advance_transmq(struct tipc_link *l, struct tipc_link *r,\n--\nnet/tipc/link.c-1627-\t\t\t\tcontinue;\nnet/tipc/link.c:1628:\t\t\thdr = buf_msg(_skb);\nnet/tipc/link.c-1629-\t\t\tmsg_set_ack(hdr, ack);\n--\nnet/tipc/link.c=1712=void tipc_link_build_reset_msg(struct tipc_link *l, struct sk_buff_head *xmitq)\n--\nnet/tipc/link.c-1724-\tif (skb \u0026\u0026 (l-\u003estate == LINK_RESET))\nnet/tipc/link.c:1725:\t\tmsg_set_peer_stopping(buf_msg(skb), 1);\nnet/tipc/link.c-1726-}\n--\nnet/tipc/link.c=1762=int tipc_link_rcv(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-1765-\tstruct sk_buff_head *defq = \u0026l-\u003edeferdq;\nnet/tipc/link.c:1766:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-1767-\tu16 seqno, rcv_nxt, win_lim;\n--\nnet/tipc/link.c-1778-\tdo {\nnet/tipc/link.c:1779:\t\thdr = buf_msg(skb);\nnet/tipc/link.c-1780-\t\tseqno = msg_seqno(hdr);\n--\nnet/tipc/link.c=1832=static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, bool probe,\n--\nnet/tipc/link.c-1862-\nnet/tipc/link.c:1863:\thdr = buf_msg(skb);\nnet/tipc/link.c-1864-\tdata = msg_data(hdr);\n--\nnet/tipc/link.c=1916=void tipc_link_create_dummy_tnl_msg(struct tipc_link *l,\n--\nnet/tipc/link.c-1933-\nnet/tipc/link.c:1934:\thdr = buf_msg(skb);\nnet/tipc/link.c-1935-\tmsg_set_msgcnt(hdr, 1);\n--\nnet/tipc/link.c=1949=void tipc_link_tnl_prepare(struct tipc_link *l, struct tipc_link *tnl,\n--\nnet/tipc/link.c-1980-\nnet/tipc/link.c:1981:\t\thdr = buf_msg(tnlskb);\nnet/tipc/link.c-1982-\t\tsyncpt = l-\u003esnd_nxt + skb_queue_len(\u0026l-\u003ebacklogq) - 1;\n--\nnet/tipc/link.c-2016-\tskb_queue_walk(queue, skb) {\nnet/tipc/link.c:2017:\t\thdr = buf_msg(skb);\nnet/tipc/link.c-2018-\t\tif (queue == \u0026l-\u003ebacklogq)\n--\nnet/tipc/link.c-2070-\t\tskb_queue_walk(\u0026tnlq, skb) {\nnet/tipc/link.c:2071:\t\t\thdr = buf_msg(skb);\nnet/tipc/link.c-2072-\t\t\tmsg_set_msgcnt(hdr, pktcnt);\n--\nnet/tipc/link.c=2174=static int tipc_link_proto_rcv(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-2176-{\nnet/tipc/link.c:2177:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-2178-\tstruct tipc_gap_ack_blks *ga = NULL;\n--\nnet/tipc/link.c-2206-\nnet/tipc/link.c:2207:\thdr = buf_msg(skb);\nnet/tipc/link.c-2208-\tdata = msg_data(hdr);\n--\nnet/tipc/link.c=2332=static bool tipc_link_build_bc_proto_msg(struct tipc_link *l, bool bcast,\n--\nnet/tipc/link.c-2345-\t\treturn false;\nnet/tipc/link.c:2346:\thdr = buf_msg(skb);\nnet/tipc/link.c-2347-\tmsg_set_last_bcast(hdr, l-\u003ebc_sndlink-\u003esnd_nxt - 1);\n--\nnet/tipc/link.c=2363=static void tipc_link_build_bc_init_msg(struct tipc_link *l,\n--\nnet/tipc/link.c-2370-\t\treturn;\nnet/tipc/link.c:2371:\tmsg_set_bc_ack_invalid(buf_msg(skb_peek(\u0026list)), true);\nnet/tipc/link.c-2372-\ttipc_link_xmit(l, \u0026list, xmitq);\n--\nnet/tipc/link.c=2495=int tipc_link_bc_nack_rcv(struct tipc_link *l, struct sk_buff *skb,\n--\nnet/tipc/link.c-2497-{\nnet/tipc/link.c:2498:\tstruct tipc_msg *hdr = buf_msg(skb);\nnet/tipc/link.c-2499-\tu32 dnode = msg_destnode(hdr);\n--\nnet/tipc/link.c=2553=static void link_print(struct tipc_link *l, const char *str)\n--\nnet/tipc/link.c-2555-\tstruct sk_buff *hskb = skb_peek(\u0026l-\u003etransmq);\nnet/tipc/link.c:2556:\tu16 head = hskb ? msg_seqno(buf_msg(hskb)) : l-\u003esnd_nxt - 1;\nnet/tipc/link.c-2557-\tu16 tail = l-\u003esnd_nxt - 1;\n--\nnet/tipc/link.c=2897=int tipc_link_dump(struct tipc_link *l, u16 dqueues, char *buf)\n--\nnet/tipc/link.c-2930-\ti += scnprintf(buf + i, sz - i, \" | %u %u %u\", len,\nnet/tipc/link.c:2931:\t\t       (hskb) ? msg_seqno(buf_msg(hskb)) : 0,\nnet/tipc/link.c:2932:\t\t       (tskb) ? msg_seqno(buf_msg(tskb)) : 0);\nnet/tipc/link.c-2933-\n--\nnet/tipc/link.c-2938-\ti += scnprintf(buf + i, sz - i, \" | %u %u %u\", len,\nnet/tipc/link.c:2939:\t\t       (hskb) ? msg_seqno(buf_msg(hskb)) : 0,\nnet/tipc/link.c:2940:\t\t       (tskb) ? msg_seqno(buf_msg(tskb)) : 0);\nnet/tipc/link.c-2941-\n--\nnet/tipc/link.c-2946-\ti += scnprintf(buf + i, sz - i, \" | %u %u %u\", len,\nnet/tipc/link.c:2947:\t\t       (hskb) ? msg_seqno(buf_msg(hskb)) : 0,\nnet/tipc/link.c:2948:\t\t       (tskb) ? msg_seqno(buf_msg(tskb)) : 0);\nnet/tipc/link.c-2949-\n--\nnet/tipc/link.c-2954-\ti += scnprintf(buf + i, sz - i, \" | %u %u %u\\n\", len,\nnet/tipc/link.c:2955:\t\t       (hskb) ? msg_seqno(buf_msg(hskb)) : 0,\nnet/tipc/link.c:2956:\t\t       (tskb) ? msg_seqno(buf_msg(tskb)) : 0);\nnet/tipc/link.c-2957-\n--\nnet/tipc/msg.c=97=struct sk_buff *tipc_msg_create(uint user, uint type,\n--\nnet/tipc/msg.c-107-\nnet/tipc/msg.c:108:\tmsg = buf_msg(buf);\nnet/tipc/msg.c-109-\ttipc_msg_init(onode, msg, user, type, hdr_sz, dnode);\n--\nnet/tipc/msg.c=124=int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)\n--\nnet/tipc/msg.c-136-\nnet/tipc/msg.c:137:\tmsg = buf_msg(frag);\nnet/tipc/msg.c-138-\tfragid = msg_type(msg);\n--\nnet/tipc/msg.c=217=int tipc_msg_append(struct tipc_msg *_hdr, struct msghdr *m, int dlen,\n--\nnet/tipc/msg.c-225-\tskb = skb_peek_tail(txq);\nnet/tipc/msg.c:226:\taccounted = skb ? msg_blocks(buf_msg(skb)) : 0;\nnet/tipc/msg.c-227-\ttotal = accounted;\n--\nnet/tipc/msg.c-235-\t\t\tskb_trim(skb, MIN_H_SIZE);\nnet/tipc/msg.c:236:\t\t\thdr = buf_msg(skb);\nnet/tipc/msg.c-237-\t\t\tskb_copy_to_linear_data(skb, _hdr, MIN_H_SIZE);\n--\nnet/tipc/msg.c-242-\t\t}\nnet/tipc/msg.c:243:\t\thdr = buf_msg(skb);\nnet/tipc/msg.c-244-\t\tcurr = msg_blocks(hdr);\n--\nnet/tipc/msg.c=268=bool tipc_msg_validate(struct sk_buff **_skb)\n--\nnet/tipc/msg.c-288-\nnet/tipc/msg.c:289:\thsz = msg_hdr_sz(buf_msg(skb));\nnet/tipc/msg.c-290-\tif (unlikely(hsz \u003c MIN_H_SIZE) || (hsz \u003e MAX_H_SIZE))\n--\nnet/tipc/msg.c-294-\nnet/tipc/msg.c:295:\thdr = buf_msg(skb);\nnet/tipc/msg.c-296-\tif (unlikely(msg_version(hdr) != TIPC_VERSION))\n--\nnet/tipc/msg.c=322=int tipc_msg_fragment(struct sk_buff *skb, const struct tipc_msg *hdr,\n--\nnet/tipc/msg.c-334-\tdata = (u8 *)skb-\u003edata;\nnet/tipc/msg.c:335:\tdsz = msg_size(buf_msg(skb));\nnet/tipc/msg.c-336-\tdmax = pktmax - INT_H_SIZE;\n--\nnet/tipc/msg.c-356-\t\t/* Update the fragment's header */\nnet/tipc/msg.c:357:\t\t_hdr = buf_msg(_skb);\nnet/tipc/msg.c-358-\t\tmsg_set_fragm_no(_hdr, pktno);\n--\nnet/tipc/msg.c=384=int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m, int offset,\n--\nnet/tipc/msg.c-479-\t} while (1);\nnet/tipc/msg.c:480:\tmsg_set_type(buf_msg(skb), LAST_FRAGMENT);\nnet/tipc/msg.c-481-\treturn dsz;\n--\nnet/tipc/msg.c=496=static bool tipc_msg_bundle(struct sk_buff *bskb, struct tipc_msg *msg,\n--\nnet/tipc/msg.c-498-{\nnet/tipc/msg.c:499:\tstruct tipc_msg *bmsg = buf_msg(bskb);\nnet/tipc/msg.c-500-\tu32 msz, bsz, offset, pad;\n--\nnet/tipc/msg.c=532=bool tipc_msg_try_bundle(struct sk_buff *tskb, struct sk_buff **skb, u32 mss,\n--\nnet/tipc/msg.c-538-\t/* First, check if the new buffer is suitable for bundling */\nnet/tipc/msg.c:539:\tmsg = buf_msg(*skb);\nnet/tipc/msg.c-540-\tif (msg_user(msg) == MSG_FRAGMENTER)\n--\nnet/tipc/msg.c-553-\t/* Is it a bundle already? Try to bundle the new message to it */\nnet/tipc/msg.c:554:\tif (msg_user(buf_msg(tskb)) == MSG_BUNDLER) {\nnet/tipc/msg.c-555-\t\t*new_bundle = false;\n--\nnet/tipc/msg.c-559-\t/* Make a new bundle of the two messages if possible */\nnet/tipc/msg.c:560:\ttsz = msg_size(buf_msg(tskb));\nnet/tipc/msg.c-561-\tif (unlikely(mss \u003c BUF_ALIGN(INT_H_SIZE + tsz) + msg_size(msg)))\n--\nnet/tipc/msg.c-565-\t\treturn true;\nnet/tipc/msg.c:566:\tinner = buf_msg(tskb);\nnet/tipc/msg.c-567-\tskb_push(tskb, INT_H_SIZE);\nnet/tipc/msg.c:568:\touter = buf_msg(tskb);\nnet/tipc/msg.c-569-\ttipc_msg_init(msg_prevnode(inner), outer, MSG_BUNDLER, 0, INT_H_SIZE,\n--\nnet/tipc/msg.c=593=bool tipc_msg_extract(struct sk_buff *skb, struct sk_buff **iskb, int *pos)\n--\nnet/tipc/msg.c-601-\nnet/tipc/msg.c:602:\thdr = buf_msg(skb);\nnet/tipc/msg.c-603-\tif (unlikely(*pos \u003e (msg_data_sz(hdr) - MIN_H_SIZE)))\n--\nnet/tipc/msg.c=637=bool tipc_msg_reverse(u32 own_node,  struct sk_buff **skb, int err)\n--\nnet/tipc/msg.c-644-\t\tgoto exit;\nnet/tipc/msg.c:645:\t_hdr = buf_msg(_skb);\nnet/tipc/msg.c-646-\tdlen = min_t(uint, msg_data_sz(_hdr), MAX_FORWARD_SIZE);\n--\nnet/tipc/msg.c-669-\t/* Build reverse header in new buffer */\nnet/tipc/msg.c:670:\thdr = buf_msg(*skb);\nnet/tipc/msg.c-671-\tmsg_set_hdr_sz(hdr, hlen);\n--\nnet/tipc/msg.c=713=bool tipc_msg_lookup_dest(struct net *net, struct sk_buff *skb, int *err)\nnet/tipc/msg.c-714-{\nnet/tipc/msg.c:715:\tstruct tipc_msg *msg = buf_msg(skb);\nnet/tipc/msg.c-716-\tu32 scope = msg_lookup_scope(msg);\n--\nnet/tipc/msg.c-730-\t\treturn false;\nnet/tipc/msg.c:731:\tmsg = buf_msg(skb);\nnet/tipc/msg.c-732-\tif (msg_reroute_cnt(msg))\n--\nnet/tipc/msg.c=776=bool tipc_msg_reassemble(struct sk_buff_head *list, struct sk_buff_head *rcvq)\n--\nnet/tipc/msg.c-785-\t\tskb = skb_peek(list);\nnet/tipc/msg.c:786:\t\thdr_len = skb_headroom(skb) + msg_hdr_sz(buf_msg(skb));\nnet/tipc/msg.c-787-\t\t_skb = __pskb_copy(skb, hdr_len, GFP_ATOMIC);\n--\nnet/tipc/msg.c=813=bool tipc_msg_pskb_copy(u32 dst, struct sk_buff_head *msg,\n--\nnet/tipc/msg.c-823-\t\t}\nnet/tipc/msg.c:824:\t\tmsg_set_destnode(buf_msg(_skb), dst);\nnet/tipc/msg.c-825-\t\t__skb_queue_tail(cpy, _skb);\n--\nnet/tipc/msg.h=186=struct tipc_gap_ack_blks {\n--\nnet/tipc/msg.h-199-\nnet/tipc/msg.h:200:static inline struct tipc_msg *buf_msg(struct sk_buff *skb)\nnet/tipc/msg.h-201-{\n--\nnet/tipc/msg.h=1184=static inline u16 buf_seqno(struct sk_buff *skb)\nnet/tipc/msg.h-1185-{\nnet/tipc/msg.h:1186:\treturn msg_seqno(buf_msg(skb));\nnet/tipc/msg.h-1187-}\n--\nnet/tipc/msg.h=1219=static inline u32 tipc_skb_peek_port(struct sk_buff_head *list, u32 filter)\n--\nnet/tipc/msg.h-1226-\tskb_queue_walk(list, skb) {\nnet/tipc/msg.h:1227:\t\tdport = msg_destport(buf_msg(skb));\nnet/tipc/msg.h-1228-\t\tif (!filter || skb_queue_is_last(list, skb))\n--\nnet/tipc/msg.h=1243=static inline struct sk_buff *tipc_skb_dequeue(struct sk_buff_head *list,\n--\nnet/tipc/msg.h-1249-\tskb_queue_walk_safe(list, _skb, tmp) {\nnet/tipc/msg.h:1250:\t\tif (msg_destport(buf_msg(_skb)) == dport) {\nnet/tipc/msg.h-1251-\t\t\t__skb_unlink(_skb, list);\n--\nnet/tipc/name_distr.c=67=static struct sk_buff *named_prepare_buf(struct net *net, u32 type, u32 size,\n--\nnet/tipc/name_distr.c-74-\tif (buf != NULL) {\nnet/tipc/name_distr.c:75:\t\tmsg = buf_msg(buf);\nnet/tipc/name_distr.c-76-\t\ttipc_msg_init(self, msg, NAME_DISTRIBUTOR,\n--\nnet/tipc/name_distr.c=88=struct sk_buff *tipc_named_publish(struct net *net, struct publication *p)\n--\nnet/tipc/name_distr.c-105-\t}\nnet/tipc/name_distr.c:106:\tmsg_set_named_seqno(buf_msg(skb), nt-\u003esnd_nxt++);\nnet/tipc/name_distr.c:107:\tmsg_set_non_legacy(buf_msg(skb));\nnet/tipc/name_distr.c:108:\titem = (struct distr_item *)msg_data(buf_msg(skb));\nnet/tipc/name_distr.c-109-\tpubl_to_item(item, p);\n--\nnet/tipc/name_distr.c=118=struct sk_buff *tipc_named_withdraw(struct net *net, struct publication *p)\n--\nnet/tipc/name_distr.c-134-\t}\nnet/tipc/name_distr.c:135:\tmsg_set_named_seqno(buf_msg(skb), nt-\u003esnd_nxt++);\nnet/tipc/name_distr.c:136:\tmsg_set_non_legacy(buf_msg(skb));\nnet/tipc/name_distr.c:137:\titem = (struct distr_item *)msg_data(buf_msg(skb));\nnet/tipc/name_distr.c-138-\tpubl_to_item(item, p);\n--\nnet/tipc/name_distr.c=150=static void named_distribute(struct net *net, struct sk_buff_head *list,\n--\nnet/tipc/name_distr.c-169-\t\t\t}\nnet/tipc/name_distr.c:170:\t\t\thdr = buf_msg(skb);\nnet/tipc/name_distr.c-171-\t\t\tmsg_set_bc_ack_invalid(hdr, true);\n--\nnet/tipc/name_distr.c-189-\tif (skb) {\nnet/tipc/name_distr.c:190:\t\thdr = buf_msg(skb);\nnet/tipc/name_distr.c-191-\t\tmsg_set_size(hdr, INT_H_SIZE + (msg_dsz - msg_rem));\n--\nnet/tipc/name_distr.c-194-\t}\nnet/tipc/name_distr.c:195:\thdr = buf_msg(skb_peek_tail(list));\nnet/tipc/name_distr.c-196-\tmsg_set_last_bulk(hdr);\n--\nnet/tipc/name_distr.c=326=static struct sk_buff *tipc_named_dequeue(struct sk_buff_head *namedq,\n--\nnet/tipc/name_distr.c-339-\t\t}\nnet/tipc/name_distr.c:340:\t\thdr = buf_msg(skb);\n\n"
}

13/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 15799
							output: 36
							thoughts: 95
						

Thoughts:
**Analyzing a Potential Null Pointer Dereference in TIPC**

Okay, so I'm looking at this code and, yep, `buf_msg` *is* defined as an inline function in `net/tipc/msg.h`. It returns a pointer to `skb->data`, cast as a `struct tipc_msg *`. The critical point here is that if `skb_peek_tail(list)` returns `NULL`, which is entirely possible, then we're passing `NULL` to `buf_msg`. That means we'd be dereferencing a `NULL` pointer with `buf_msg(NULL)`. That's a classic recipe for a kernel panic, and something I need to fix. Just to be completely sure, I'm going to quickly double-check the definition of `buf_msg`. I'll jump to `net/tipc/msg.h` line 200, to make certain nothing unexpected is happening with how this inline function is defined. Need to make sure the fix addresses the root cause correctly.



14/2 2026/07/07 00:40 tool read-file
0m Args:
{
  "File": "net/tipc/msg.h",
  "FirstLine": 195,
  "LineCount": 10
}

Results:
{
  "Contents": " 195:\t\n 196:\t#define MAX_GAP_ACK_BLKS\t128\n 197:\t#define MAX_GAP_ACK_BLKS_SZ\t(sizeof(struct tipc_gap_ack_blks) + \\\n 198:\t\t\t\t\t sizeof(struct tipc_gap_ack) * MAX_GAP_ACK_BLKS)\n 199:\t\n 200:\tstatic inline struct tipc_msg *buf_msg(struct sk_buff *skb)\n 201:\t{\n 202:\t\treturn (struct tipc_msg *)skb-\u003edata;\n 203:\t}\n 204:\t\n"
}

15/2 2026/07/07 00:40 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 16337
							output: 33
							thoughts: 155
						

Thoughts:
**Analyzing a Potential Null-Pointer Dereference**

Okay, so I'm looking at this code, and it's clear: `buf_msg` is dereferencing `skb`. If `skb` is, in fact, NULL, we're staring down the barrel of a classic null-pointer dereference. This patch seems to be addressing a potential flaw in `named_distribute`, specifically when `nt->cluster_scope` is empty. Right, that makes sense. It's happening within `tipc_named_node_up`.

The situation arises in `tipc_named_node_up` when a TIPC node is coming online, and its `nt->cluster_scope` happens to be empty. An empty `cluster_scope` means there are no publications within the cluster, which is a definable situation.

So, this looks like a genuine functional change; it's fixing a real bug. Now, my next step is to nail down the call chain. I need to trace exactly where `tipc_named_node_up` is invoked to fully understand the context.



16/2 2026/07/07 00:41 tool grepper
0m Args:
{
  "Expression": "tipc_named_node_up",
  "PathPrefix": "net/tipc/"
}

Results:
{
  "Output": "net/tipc/name_distr.c=150=static void named_distribute(struct net *net, struct sk_buff_head *list,\n--\nnet/tipc/name_distr.c-200-/**\nnet/tipc/name_distr.c:201: * tipc_named_node_up - tell specified node about all publications by this node\nnet/tipc/name_distr.c-202- * @net: the associated network namespace\n--\nnet/tipc/name_distr.c-205- */\nnet/tipc/name_distr.c:206:void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)\nnet/tipc/name_distr.c-207-{\n--\nnet/tipc/name_distr.h=71=struct sk_buff *tipc_named_withdraw(struct net *net, struct publication *publ);\nnet/tipc/name_distr.h:72:void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities);\nnet/tipc/name_distr.h-73-void tipc_named_rcv(struct net *net, struct sk_buff_head *namedq,\n--\nnet/tipc/node.c=396=static void tipc_node_write_unlock(struct tipc_node *n)\n--\nnet/tipc/node.c-427-\tif (flags \u0026 TIPC_NOTIFY_NODE_UP)\nnet/tipc/node.c:428:\t\ttipc_named_node_up(net, node, n-\u003ecapabilities);\nnet/tipc/node.c-429-\n"
}

17/2 2026/07/07 00:41 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 17207
							output: 30
							thoughts: 96
						

Thoughts:
**Fuzzing the TIPC Node Unlock Routine**

Okay, so the `tipc_node_write_unlock` function is called when the `TIPC_NOTIFY_NODE_UP` flag is active. This is a crucial component of TIPC's node discovery and connection establishment, right? Given its central role, this function is a prime target for fuzzing. We need to prioritize this.

Let's figure out the right configuration options needed to enable TIPC. It seems the primary one is just `TIPC`, but I want to be certain there are no other dependent configs we're missing. Better to be thorough. I'll take another look at the `net/tipc/Kconfig` file and double-check to make sure we have all the prerequisites covered.



18/2 2026/07/07 00:41 tool grepper
0m Args:
{
  "Expression": "config TIPC",
  "PathPrefix": "net/tipc/Kconfig"
}

Results:
{
  "Output": "net/tipc/Kconfig-5-\nnet/tipc/Kconfig:6:menuconfig TIPC\nnet/tipc/Kconfig-7-\ttristate \"The TIPC Protocol\"\n--\nnet/tipc/Kconfig-23-\nnet/tipc/Kconfig:24:config TIPC_MEDIA_IB\nnet/tipc/Kconfig-25-\tbool \"InfiniBand media type support\"\n--\nnet/tipc/Kconfig-29-\t  IP-over-InfiniBand devices.\nnet/tipc/Kconfig:30:config TIPC_MEDIA_UDP\nnet/tipc/Kconfig-31-\tbool \"IP/UDP media type support\"\n--\nnet/tipc/Kconfig-37-\nnet/tipc/Kconfig:38:config TIPC_CRYPTO\nnet/tipc/Kconfig-39-\tbool \"TIPC encryption support\"\n--\nnet/tipc/Kconfig-52-\nnet/tipc/Kconfig:53:config TIPC_DIAG\nnet/tipc/Kconfig-54-\ttristate \"TIPC: socket monitoring interface\"\n"
}

19/2 2026/07/07 00:41 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 17788
							output: 24
							thoughts: 181
						

Thoughts:
**My Configuration Checklist**

Okay, so I'm configuring this system. The primary configuration, the backbone, is going to be `TIPC`. Now, for the UDP testing I want to do, I'll definitely need `TIPC_MEDIA_UDP`. Let's include both `TIPC` and `TIPC_MEDIA_UDP` in the mix.

Now, about those FocusSymbols. That's where things get interesting. I've got `tipc_named_node_up`, which is the modified function, and the potentially problematic function, `named_distribute`, which was likely the point of failure. It's a key piece, so I'll be adding both `tipc_named_node_up` and `named_distribute` to the FocusSymbols list.

It’s crucial to understand how frequently `named_distribute` is hit. I’m fairly certain it's not a performance bottleneck at runtime, since it is only called on node startup, not per-packet. And it is the same with `tipc_named_node_up`, so it should not be on a hot path either.

Let's do a quick scan to make sure I haven't overlooked any other relevant configurations. Just double checking everything.



20/2 2026/07/07 00:41 tool grepper
0m Args:
{
  "Expression": "depends on TIPC",
  "PathPrefix": ""
}

Results:
{
  "Output": "net/tipc/Kconfig=24=config TIPC_MEDIA_IB\nnet/tipc/Kconfig-25-\tbool \"InfiniBand media type support\"\nnet/tipc/Kconfig:26:\tdepends on TIPC \u0026\u0026 INFINIBAND_IPOIB\nnet/tipc/Kconfig-27-\thelp\n--\nnet/tipc/Kconfig=30=config TIPC_MEDIA_UDP\nnet/tipc/Kconfig-31-\tbool \"IP/UDP media type support\"\nnet/tipc/Kconfig:32:\tdepends on TIPC\nnet/tipc/Kconfig-33-\tselect NET_UDP_TUNNEL\n--\nnet/tipc/Kconfig=38=config TIPC_CRYPTO\nnet/tipc/Kconfig-39-\tbool \"TIPC encryption support\"\nnet/tipc/Kconfig:40:\tdepends on TIPC\nnet/tipc/Kconfig-41-\tselect CRYPTO\n--\nnet/tipc/Kconfig=53=config TIPC_DIAG\nnet/tipc/Kconfig-54-\ttristate \"TIPC: socket monitoring interface\"\nnet/tipc/Kconfig:55:\tdepends on TIPC\nnet/tipc/Kconfig-56-\tdefault y\n"
}

21/2 2026/07/07 00:41 llm patch-evaluator
0m Model:
gemini-3.1-pro-preview

Args:
null

Results:
null

Tokens:
							input: 18584
							output: 132
							thoughts: 283
						

Thoughts:
**Analyzing a TIPC Bug Fix**

Okay, so `TIPC` and `TIPC_MEDIA_UDP` are solid, let's move forward. I'm taking another quick look at this patch:

```c
 	read_lock_bh(&nt->cluster_scope_lock);
+	if (list_empty(&nt->cluster_scope)) {
+		read_unlock_bh(&nt->cluster_scope_lock);
+		return;
+	}
 	named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
 	tipc_node_xmit(net, &head, dnode, 0);
 	read_unlock_bh(&nt->cluster_scope_lock);
```

Right, it's a straightforward bug fix. We're dealing with a possible null pointer dereference or, more precisely, improper handling of an empty list, specifically `nt->cluster_scope`. This could occur during TIPC node discovery, as the code now explicitly checks for an empty list before calling `named_distribute`. The fix prevents the function from attempting to process an empty list, averting a potential crash.

My assessment is that this warrants fuzzing. `WorthFuzzing` is true, and the key symbols to target are `tipc_named_node_up` and `named_distribute`. The fuzzing strategy should concentrate on TIPC node connections and publication distribution to trigger this specific codepath. The existing configs are fine. It seems that we are safe.



22/2 2026/07/07 00:41 tool set-results
0m Args:
{
  "EnableConfigs": [
    "TIPC",
    "TIPC_MEDIA_UDP"
  ],
  "FocusSymbols": [
    "tipc_named_node_up",
    "named_distribute"
  ],
  "Reasoning": "The patch fixes a potential null-pointer dereference in `named_distribute` (called by `tipc_named_node_up`) that occurs when `nt-\u003ecluster_scope` is empty during TIPC node discovery. Fuzzing should focus on TIPC node connection and publication distribution to ensure the empty list case is properly handled.",
  "WorthFuzzing": true
}

Results:
{
  "EnableConfigs": [
    "TIPC",
    "TIPC_MEDIA_UDP"
  ],
  "FocusSymbols": [
    "tipc_named_node_up",
    "named_distribute"
  ],
  "Reasoning": "The patch fixes a potential null-pointer dereference in `named_distribute` (called by `tipc_named_node_up`) that occurs when `nt-\u003ecluster_scope` is empty during TIPC node discovery. Fuzzing should focus on TIPC node connection and publication distribution to ensure the empty list case is properly handled.",
  "WorthFuzzing": true
}

LLM Calls Summary:
Total Calls Total Tokens Avg Tokens Total Duration (Seconds) Avg Duration (Seconds)
Tool Calls Summary:
Total Calls Total Duration (Seconds) Avg Duration (Seconds)