| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/21 00:42 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": [
"NFC",
"NFC_NCI",
"NFC_VIRTUAL_NCI"
],
"FocusSymbols": [
"nci_queue_tx_data_frags",
"nci_send_data"
],
"KMSANReasoning": "The patch addresses a concurrency and infinite loop issue in `nci_queue_tx_data_frags` by capturing `conn_info-\u003emax_pkt_payload_len` with `READ_ONCE()` into a local variable `max_len` and validating that `max_len` is non-zero before chunking outgoing packets.\n\nThis modification does not touch any uninitialized stack or heap allocations, does not copy kernel memory to user space, and does not alter buffer bounds in a manner that could expose uninitialized memory. The underlying issue is an infinite loop / hung task and a data race, which fall under standard kernel testing / KCSAN / lockup detectors, rather than uninitialized memory access detectable by KMSAN. Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies nci_queue_tx_data_frags() in net/nfc/nci/data.c to read conn_info-\u003emax_pkt_payload_len once using READ_ONCE() and validate that max_len is non-zero, preventing an infinite fragmentation loop or data race with concurrent rx updates. This logic is part of the NFC/NCI stack and is reachable in virtualized environments via virtual NCI devices (CONFIG_NFC_VIRTUAL_NCI), emulated USB NFC devices, and AF_NFC sockets. Therefore, it is worth fuzzing.",
"WorthFuzzing": true
} |
| 1/1 | 2026/09/21 00:42 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit f406106506b247b86cd0c084060b96e1bc8ac280\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Sep 21 00:42:26 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c\nindex 4253edea5c8db..eeb5260c5d676 100644\n--- a/net/nfc/nci/data.c\n+++ b/net/nfc/nci/data.c\n@@ -104,6 +104,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n \tstruct sk_buff_head frags_q;\n \tstruct sk_buff *skb_frag;\n \tint frag_len;\n+\tu8 max_len;\n \tint rc = 0;\n \n \tpr_debug(\"conn_id 0x%x, total_len %d\\n\", conn_id, total_len);\n@@ -114,11 +115,18 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n \t\tgoto exit;\n \t}\n \n+\t/* the rx workqueue may update the field concurrently */\n+\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\n+\n+\tif (!max_len) {\n+\t\trc = -EPROTO;\n+\t\tgoto exit;\n+\t}\n+\n \t__skb_queue_head_init(\u0026frags_q);\n \n \twhile (total_len) {\n-\t\tfrag_len =\n-\t\t\tmin_t(int, total_len, conn_info-\u003emax_pkt_payload_len);\n+\t\tfrag_len = min_t(int, total_len, max_len);\n \n \t\tskb_frag = nci_skb_alloc(ndev,\n \t\t\t\t\t (NCI_DATA_HDR_SIZE + frag_len),\n"
} |
| 2/1 | 2026/09/21 00:42 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": [
"NFC",
"NFC_NCI",
"NFC_VIRTUAL_NCI"
],
"FocusSymbols": [
"nci_queue_tx_data_frags",
"nci_send_data"
],
"Reasoning": "The patch modifies nci_queue_tx_data_frags() in net/nfc/nci/data.c to read conn_info-\u003emax_pkt_payload_len once using READ_ONCE() and validate that max_len is non-zero, preventing an infinite fragmentation loop or data race with concurrent rx updates. This logic is part of the NFC/NCI stack and is reachable in virtualized environments via virtual NCI devices (CONFIG_NFC_VIRTUAL_NCI), emulated USB NFC devices, and AF_NFC sockets. Therefore, it is worth fuzzing.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any '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: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit f406106506b247b86cd0c084060b96e1bc8ac280
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 21 00:42:26 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 4253edea5c8db..eeb5260c5d676 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -104,6 +104,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
struct sk_buff_head frags_q;
struct sk_buff *skb_frag;
int frag_len;
+ u8 max_len;
int rc = 0;
pr_debug("conn_id 0x%x, total_len %d\n", conn_id, total_len);
@@ -114,11 +115,18 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
goto exit;
}
+ /* the rx workqueue may update the field concurrently */
+ max_len = READ_ONCE(conn_info->max_pkt_payload_len);
+
+ if (!max_len) {
+ rc = -EPROTO;
+ goto exit;
+ }
+
__skb_queue_head_init(&frags_q);
while (total_len) {
- frag_len =
- min_t(int, total_len, conn_info->max_pkt_payload_len);
+ frag_len = min_t(int, total_len, max_len);
skb_frag = nci_skb_alloc(ndev,
(NCI_DATA_HDR_SIZE + frag_len),
|
| 3/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3124 output: 38 thoughts: 57 Thoughts: **Analyzing the NFC Data Patch** Okay, so this patch is touching `net/nfc/nci/data.c`. My first instinct, as always, is to dive right in and understand the context. I need to see what's being changed and why. Given my expertise, a superficial glance isn't going to cut it; I need to thoroughly assess the impact. So, I'm going to reach for either `read-file` or `grepper` – whatever's most efficient at the moment – to get a good look at `net/nfc/nci/data.c` itself. I need a clear view of the surrounding code; I need to establish a baseline. I want to refresh my understanding of its structure and purpose before getting into the specifics of the patch. I'm looking for the "before" picture, the starting point, so I can accurately judge the significance and implications of this modification. |
| 4/2 | 2026/09/21 00:42 | tool | read-file |
0mArgs:{
"File": "net/nfc/nci/data.c",
"FirstLine": 95,
"LineCount": 50
}Results: {
"Contents": " 95:\tEXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);\n 96:\t\n 97:\tstatic int nci_queue_tx_data_frags(struct nci_dev *ndev,\n 98:\t\t\t\t\t __u8 conn_id,\n 99:\t\t\t\t\t struct sk_buff *skb) {\n 100:\t\tconst struct nci_conn_info *conn_info;\n 101:\t\tint total_len = skb-\u003elen;\n 102:\t\tconst unsigned char *data = skb-\u003edata;\n 103:\t\tunsigned long flags;\n 104:\t\tstruct sk_buff_head frags_q;\n 105:\t\tstruct sk_buff *skb_frag;\n 106:\t\tint frag_len;\n 107:\t\tu8 max_len;\n 108:\t\tint rc = 0;\n 109:\t\n 110:\t\tpr_debug(\"conn_id 0x%x, total_len %d\\n\", conn_id, total_len);\n 111:\t\n 112:\t\tconn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);\n 113:\t\tif (!conn_info) {\n 114:\t\t\trc = -EPROTO;\n 115:\t\t\tgoto exit;\n 116:\t\t}\n 117:\t\n 118:\t\t/* the rx workqueue may update the field concurrently */\n 119:\t\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\n 120:\t\n 121:\t\tif (!max_len) {\n 122:\t\t\trc = -EPROTO;\n 123:\t\t\tgoto exit;\n 124:\t\t}\n 125:\t\n 126:\t\t__skb_queue_head_init(\u0026frags_q);\n 127:\t\n 128:\t\twhile (total_len) {\n 129:\t\t\tfrag_len = min_t(int, total_len, max_len);\n 130:\t\n 131:\t\t\tskb_frag = nci_skb_alloc(ndev,\n 132:\t\t\t\t\t\t (NCI_DATA_HDR_SIZE + frag_len),\n 133:\t\t\t\t\t\t GFP_ATOMIC);\n 134:\t\t\tif (skb_frag == NULL) {\n 135:\t\t\t\trc = -ENOMEM;\n 136:\t\t\t\tgoto free_exit;\n 137:\t\t\t}\n 138:\t\t\tskb_reserve(skb_frag, NCI_DATA_HDR_SIZE);\n 139:\t\n 140:\t\t\t/* first, copy the data */\n 141:\t\t\tskb_put_data(skb_frag, data, frag_len);\n 142:\t\n 143:\t\t\t/* second, set the header */\n 144:\t\t\tnci_push_data_hdr(ndev, conn_id, skb_frag,\n"
} |
| 5/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4207 output: 35 thoughts: 37 Thoughts: Here's my analysis of the situation, presented from my perspective as an expert: **Investigating `nci_queue_tx_data_frags` in `net/nfc/nci/data.c`** Okay, so I need to understand the role of `nci_queue_tx_data_frags`. My immediate thought is to locate where this function is called, specifically within `net/nfc/nci/data.c`. Knowing the call sites is absolutely crucial to grasping its purpose and the flow of data involved in the NFC (Near Field Communication) context. I'll need to examine the surrounding code as well to get a feel for the data structures being passed and any potential locks or synchronization mechanisms at play. Understanding the function's callers will give me valuable insight into the overall TX (Transmit) data path within the NCI (NFC Controller Interface) layer, helping to clarify how data fragments are managed before being sent over the air. I'll probably start with a `grep` or similar search to identify the call sites, then meticulously examine the context of each call. This is going to be about understanding the data flow and how it's handled within the NCI framework. |
| 6/2 | 2026/09/21 00:42 | tool | grepper |
0mArgs:{
"Expression": "nci_queue_tx_data_frags",
"PathPrefix": "net/nfc"
}Results: {
"Output": "net/nfc/nci/data.c=95=EXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);\nnet/nfc/nci/data.c-96-\nnet/nfc/nci/data.c:97:static int nci_queue_tx_data_frags(struct nci_dev *ndev,\nnet/nfc/nci/data.c-98-\t\t\t\t __u8 conn_id,\n--\nnet/nfc/nci/data.c=179=int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\n--\nnet/nfc/nci/data.c-199-\t\t/* fragment packet and queue the fragments */\nnet/nfc/nci/data.c:200:\t\trc = nci_queue_tx_data_frags(ndev, conn_id, skb);\nnet/nfc/nci/data.c-201-\t\tif (rc) {\n"
} |
| 7/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4806 output: 30 thoughts: 14 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Analyzing `nci_send_data` Callers** Alright, let's dive in. The goal here is pretty straightforward: I need to quickly identify and understand the various points in the code where the `nci_send_data` function is being invoked. This could be for a variety of reasons – debugging a data transmission issue, tracing the flow of data, understanding how different modules interact, or perhaps even preparing for a refactor. Essentially, I'm thinking about the static analysis required to understand the contexts within which `nci_send_data` is being called. I'm going to start with the simplest approach, which is a code search. Then, depending on how large the codebase is, I will have to decide what else will be needed to get a full understanding. Am I going to have to resort to dynamic analysis? Are there any tools I can leverage to make this easier, like a call graph generator? I should also take into account if the calls are made from C, C++, or even another language entirely. Any preprocessor directives in the code could complicate this process. I will need to be sure to consider those as well. |
| 8/2 | 2026/09/21 00:42 | tool | grepper |
0mArgs:{
"Expression": "nci_send_data",
"PathPrefix": "net/nfc"
}Results: {
"Output": "net/nfc/nci/core.c=397=struct nci_loopback_data {\n--\nnet/nfc/nci/core.c-401-\nnet/nfc/nci/core.c:402:static void nci_send_data_req(struct nci_dev *ndev, const void *opt)\nnet/nfc/nci/core.c-403-{\n--\nnet/nfc/nci/core.c-405-\nnet/nfc/nci/core.c:406:\tnci_send_data(ndev, data-\u003econn_id, data-\u003edata);\nnet/nfc/nci/core.c-407-}\n--\nnet/nfc/nci/core.c=425=int nci_nfcc_loopback(struct nci_dev *ndev, const void *data, size_t data_len,\n--\nnet/nfc/nci/core.c-464-\tndev-\u003ecur_conn_id = conn_id;\nnet/nfc/nci/core.c:465:\tr = nci_request(ndev, nci_send_data_req, \u0026loopback_data,\nnet/nfc/nci/core.c-466-\t\t\tmsecs_to_jiffies(NCI_DATA_TIMEOUT));\n--\nnet/nfc/nci/core.c=1040=static int nci_transceive(struct nfc_dev *nfc_dev, struct nfc_target *target,\n--\nnet/nfc/nci/core.c-1070-\nnet/nfc/nci/core.c:1071:\trc = nci_send_data(ndev, NCI_STATIC_RF_CONN_ID, skb);\nnet/nfc/nci/core.c-1072-\tif (rc)\n--\nnet/nfc/nci/core.c=1078=static int nci_tm_send(struct nfc_dev *nfc_dev, struct sk_buff *skb)\n--\nnet/nfc/nci/core.c-1082-\nnet/nfc/nci/core.c:1083:\trc = nci_send_data(ndev, NCI_STATIC_RF_CONN_ID, skb);\nnet/nfc/nci/core.c-1084-\tif (rc)\n--\nnet/nfc/nci/data.c=97=static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n--\nnet/nfc/nci/data.c-178-/* Send NCI data */\nnet/nfc/nci/data.c:179:int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\nnet/nfc/nci/data.c-180-{\n--\nnet/nfc/nci/data.c-217-}\nnet/nfc/nci/data.c:218:EXPORT_SYMBOL(nci_send_data);\nnet/nfc/nci/data.c-219-\n--\nnet/nfc/nci/hci.c=142=static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,\n--\nnet/nfc/nci/hci.c-178-\nnet/nfc/nci/hci.c:179:\t\tr = nci_send_data(ndev, conn_info-\u003econn_id, skb);\nnet/nfc/nci/hci.c-180-\t\tif (r \u003c 0)\n"
} |
| 9/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6056 output: 26 thoughts: 350 Thoughts: **Analyzing a Potential Vulnerability in NFC/NCI Data Fragment Queuing** Okay, let's dissect this `nci_queue_tx_data_frags` function. The original code had a glaring issue. If `conn_info->max_pkt_payload_len` was zero, we'd hit an infinite loop. Even worse, concurrent updates from the RX workqueue could *also* result in `conn_info->max_pkt_payload_len` being set to zero mid-execution, leading to a race condition and a similar hang. The patch provides a clear solution. It's now reading `conn_info->max_pkt_payload_len` safely using `READ_ONCE` before entering the loop. It then checks for a zero value, returning an error (`-EPROTO`) if encountered. This prevents the infinite loop. The critical aspect here is the atomic read to avoid the race condition. Now, my next thought: can we trigger this in syzkaller? We have NFC support in syzkaller, which means we can likely manipulate virtual NFC devices, potentially using `nfcsim` or raw socket interfaces, or even virtual drivers. This gives us a foothold to experiment. My next step will be to explore the NFC and NCI configuration within syzkaller, specifically looking at the Kconfig options under `net/nfc/nci`. We need to understand how the NFC/NCI stack is set up and used within the fuzzing environment to see if we can craft a scenario where we can control `conn_info->max_pkt_payload_len` and trigger this potential vulnerability. |
| 10/2 | 2026/09/21 00:42 | tool | grepper |
0mArgs:{
"Expression": "NCI",
"PathPrefix": "net/nfc"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 1944 lines.\nUse more precise expression if possible.\n\nnet/nfc/Makefile=6=obj-$(CONFIG_NFC) += nfc.o\nnet/nfc/Makefile:7:obj-$(CONFIG_NFC_NCI) += nci/\nnet/nfc/Makefile-8-obj-$(CONFIG_NFC_HCI) += hci/\n--\nnet/nfc/nci/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\nnet/nfc/nci/Kconfig:2:config NFC_NCI\nnet/nfc/nci/Kconfig-3-\tdepends on NFC\nnet/nfc/nci/Kconfig:4:\ttristate \"NCI protocol support\"\nnet/nfc/nci/Kconfig-5-\tdefault n\nnet/nfc/nci/Kconfig-6-\thelp\nnet/nfc/nci/Kconfig:7:\t NCI (NFC Controller Interface) is a communication protocol between\nnet/nfc/nci/Kconfig-8-\t an NFC Controller (NFCC) and a Device Host (DH).\nnet/nfc/nci/Kconfig-9-\nnet/nfc/nci/Kconfig:10:\t Say Y here to compile NCI support into the kernel or say M to\nnet/nfc/nci/Kconfig-11-\t compile it as module (nci).\nnet/nfc/nci/Kconfig-12-\nnet/nfc/nci/Kconfig:13:config NFC_NCI_SPI\nnet/nfc/nci/Kconfig:14:\tdepends on NFC_NCI \u0026\u0026 SPI\nnet/nfc/nci/Kconfig-15-\tselect CRC_CCITT\nnet/nfc/nci/Kconfig:16:\ttristate \"NCI over SPI protocol support\"\nnet/nfc/nci/Kconfig-17-\tdefault n\nnet/nfc/nci/Kconfig-18-\thelp\nnet/nfc/nci/Kconfig:19:\t NCI (NFC Controller Interface) is a communication protocol between\nnet/nfc/nci/Kconfig-20-\t an NFC Controller (NFCC) and a Device Host (DH).\nnet/nfc/nci/Kconfig-21-\nnet/nfc/nci/Kconfig:22:\t Say yes if you use an NCI driver that requires SPI link layer.\nnet/nfc/nci/Kconfig-23-\nnet/nfc/nci/Kconfig:24:config NFC_NCI_UART\nnet/nfc/nci/Kconfig:25:\tdepends on NFC_NCI \u0026\u0026 TTY\nnet/nfc/nci/Kconfig:26:\ttristate \"NCI over UART protocol support\"\nnet/nfc/nci/Kconfig-27-\tdefault n\nnet/nfc/nci/Kconfig-28-\thelp\nnet/nfc/nci/Kconfig:29:\t Say yes if you use an NCI driver that requires UART link layer.\n--\nnet/nfc/nci/Makefile-2-#\nnet/nfc/nci/Makefile:3:# Makefile for the Linux NFC NCI layer.\nnet/nfc/nci/Makefile-4-#\nnet/nfc/nci/Makefile-5-\nnet/nfc/nci/Makefile:6:obj-$(CONFIG_NFC_NCI) += nci.o\nnet/nfc/nci/Makefile-7-\n--\nnet/nfc/nci/Makefile=10=nci_spi-y += spi.o\nnet/nfc/nci/Makefile:11:obj-$(CONFIG_NFC_NCI_SPI) += nci_spi.o\nnet/nfc/nci/Makefile-12-\nnet/nfc/nci/Makefile=13=nci_uart-y += uart.o\nnet/nfc/nci/Makefile:14:obj-$(CONFIG_NFC_NCI_UART) += nci_uart.o\n--\nnet/nfc/nci/core.c=74=EXPORT_SYMBOL(nci_get_conn_info_by_dest_type_params);\nnet/nfc/nci/core.c-75-\nnet/nfc/nci/core.c:76:/* ---- NCI requests ---- */\nnet/nfc/nci/core.c-77-\nnet/nfc/nci/core.c=78=void nci_req_complete(struct nci_dev *ndev, int result)\nnet/nfc/nci/core.c-79-{\nnet/nfc/nci/core.c:80:\tif (ndev-\u003ereq_status == NCI_REQ_PEND) {\nnet/nfc/nci/core.c-81-\t\tndev-\u003ereq_result = result;\nnet/nfc/nci/core.c:82:\t\tndev-\u003ereq_status = NCI_REQ_DONE;\nnet/nfc/nci/core.c-83-\t\tcomplete(\u0026ndev-\u003ereq_completion);\n--\nnet/nfc/nci/core.c=88=static void nci_req_cancel(struct nci_dev *ndev, int err)\nnet/nfc/nci/core.c-89-{\nnet/nfc/nci/core.c:90:\tif (ndev-\u003ereq_status == NCI_REQ_PEND) {\nnet/nfc/nci/core.c-91-\t\tndev-\u003ereq_result = err;\nnet/nfc/nci/core.c:92:\t\tndev-\u003ereq_status = NCI_REQ_CANCELED;\nnet/nfc/nci/core.c-93-\t\tcomplete(\u0026ndev-\u003ereq_completion);\n--\nnet/nfc/nci/core.c=98=static int __nci_request(struct nci_dev *ndev,\n--\nnet/nfc/nci/core.c-104-\nnet/nfc/nci/core.c:105:\tndev-\u003ereq_status = NCI_REQ_PEND;\nnet/nfc/nci/core.c-106-\n--\nnet/nfc/nci/core.c-116-\t\tswitch (ndev-\u003ereq_status) {\nnet/nfc/nci/core.c:117:\t\tcase NCI_REQ_DONE:\nnet/nfc/nci/core.c-118-\t\t\trc = nci_to_errno(ndev-\u003ereq_result);\n--\nnet/nfc/nci/core.c-120-\nnet/nfc/nci/core.c:121:\t\tcase NCI_REQ_CANCELED:\nnet/nfc/nci/core.c-122-\t\t\trc = -ndev-\u003ereq_result;\n--\nnet/nfc/nci/core.c=141=inline int nci_request(struct nci_dev *ndev,\n--\nnet/nfc/nci/core.c-152-\t */\nnet/nfc/nci/core.c:153:\tif (test_bit(NCI_UP, \u0026ndev-\u003eflags))\nnet/nfc/nci/core.c-154-\t\trc = __nci_request(ndev, req, opt, timeout);\n--\nnet/nfc/nci/core.c=162=static void nci_reset_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-165-\nnet/nfc/nci/core.c:166:\tcmd.reset_type = NCI_RESET_TYPE_RESET_CONFIG;\nnet/nfc/nci/core.c:167:\tnci_send_cmd(ndev, NCI_OP_CORE_RESET_CMD, 1, \u0026cmd);\nnet/nfc/nci/core.c-168-}\n--\nnet/nfc/nci/core.c=170=static void nci_init_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-176-\nnet/nfc/nci/core.c:177:\tnci_send_cmd(ndev, NCI_OP_CORE_INIT_CMD, plen, opt);\nnet/nfc/nci/core.c-178-}\n--\nnet/nfc/nci/core.c=180=static void nci_init_complete_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-189-\nnet/nfc/nci/core.c:190:\t/* by default mapping is set to NCI_RF_INTERFACE_FRAME */\nnet/nfc/nci/core.c-191-\tfor (i = 0; i \u003c ndev-\u003enum_supported_rf_interfaces; i++) {\nnet/nfc/nci/core.c-192-\t\tif (ndev-\u003esupported_rf_interfaces[i] ==\nnet/nfc/nci/core.c:193:\t\t NCI_RF_INTERFACE_ISO_DEP) {\nnet/nfc/nci/core.c:194:\t\t\tcfg[*num].rf_protocol = NCI_RF_PROTOCOL_ISO_DEP;\nnet/nfc/nci/core.c:195:\t\t\tcfg[*num].mode = NCI_DISC_MAP_MODE_POLL |\nnet/nfc/nci/core.c:196:\t\t\t\tNCI_DISC_MAP_MODE_LISTEN;\nnet/nfc/nci/core.c:197:\t\t\tcfg[*num].rf_interface = NCI_RF_INTERFACE_ISO_DEP;\nnet/nfc/nci/core.c-198-\t\t\t(*num)++;\nnet/nfc/nci/core.c-199-\t\t} else if (ndev-\u003esupported_rf_interfaces[i] ==\nnet/nfc/nci/core.c:200:\t\t\t NCI_RF_INTERFACE_NFC_DEP) {\nnet/nfc/nci/core.c:201:\t\t\tcfg[*num].rf_protocol = NCI_RF_PROTOCOL_NFC_DEP;\nnet/nfc/nci/core.c:202:\t\t\tcfg[*num].mode = NCI_DISC_MAP_MODE_POLL |\nnet/nfc/nci/core.c:203:\t\t\t\tNCI_DISC_MAP_MODE_LISTEN;\nnet/nfc/nci/core.c:204:\t\t\tcfg[*num].rf_interface = NCI_RF_INTERFACE_NFC_DEP;\nnet/nfc/nci/core.c-205-\t\t\t(*num)++;\n--\nnet/nfc/nci/core.c-207-\nnet/nfc/nci/core.c:208:\t\tif (*num == NCI_MAX_NUM_MAPPING_CONFIGS)\nnet/nfc/nci/core.c-209-\t\t\tbreak;\n--\nnet/nfc/nci/core.c-211-\nnet/nfc/nci/core.c:212:\tnci_send_cmd(ndev, NCI_OP_RF_DISCOVER_MAP_CMD,\nnet/nfc/nci/core.c-213-\t\t (1 + ((*num) * sizeof(struct disc_map_config))), \u0026cmd);\n--\nnet/nfc/nci/core.c=222=static void nci_set_config_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-226-\nnet/nfc/nci/core.c:227:\tBUG_ON(param-\u003elen \u003e NCI_MAX_PARAM_LEN);\nnet/nfc/nci/core.c-228-\n--\nnet/nfc/nci/core.c-233-\nnet/nfc/nci/core.c:234:\tnci_send_cmd(ndev, NCI_OP_CORE_SET_CONFIG_CMD, (3 + param-\u003elen), \u0026cmd);\nnet/nfc/nci/core.c-235-}\n--\nnet/nfc/nci/core.c=242=static void nci_rf_discover_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-248-\nnet/nfc/nci/core.c:249:\tif ((cmd.num_disc_configs \u003c NCI_MAX_NUM_RF_CONFIGS) \u0026\u0026\nnet/nfc/nci/core.c-250-\t (param-\u003eim_protocols \u0026 NFC_PROTO_JEWEL_MASK ||\n--\nnet/nfc/nci/core.c-254-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:255:\t\t\tNCI_NFC_A_PASSIVE_POLL_MODE;\nnet/nfc/nci/core.c-256-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-259-\nnet/nfc/nci/core.c:260:\tif ((cmd.num_disc_configs \u003c NCI_MAX_NUM_RF_CONFIGS) \u0026\u0026\nnet/nfc/nci/core.c-261-\t (param-\u003eim_protocols \u0026 NFC_PROTO_ISO14443_B_MASK)) {\nnet/nfc/nci/core.c-262-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:263:\t\t\tNCI_NFC_B_PASSIVE_POLL_MODE;\nnet/nfc/nci/core.c-264-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-267-\nnet/nfc/nci/core.c:268:\tif ((cmd.num_disc_configs \u003c NCI_MAX_NUM_RF_CONFIGS) \u0026\u0026\nnet/nfc/nci/core.c-269-\t (param-\u003eim_protocols \u0026 NFC_PROTO_FELICA_MASK ||\n--\nnet/nfc/nci/core.c-271-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:272:\t\t\tNCI_NFC_F_PASSIVE_POLL_MODE;\nnet/nfc/nci/core.c-273-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-276-\nnet/nfc/nci/core.c:277:\tif ((cmd.num_disc_configs \u003c NCI_MAX_NUM_RF_CONFIGS) \u0026\u0026\nnet/nfc/nci/core.c-278-\t (param-\u003eim_protocols \u0026 NFC_PROTO_ISO15693_MASK)) {\nnet/nfc/nci/core.c-279-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:280:\t\t\tNCI_NFC_V_PASSIVE_POLL_MODE;\nnet/nfc/nci/core.c-281-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-284-\nnet/nfc/nci/core.c:285:\tif ((cmd.num_disc_configs \u003c NCI_MAX_NUM_RF_CONFIGS - 1) \u0026\u0026\nnet/nfc/nci/core.c-286-\t (param-\u003etm_protocols \u0026 NFC_PROTO_NFC_DEP_MASK)) {\nnet/nfc/nci/core.c-287-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:288:\t\t\tNCI_NFC_A_PASSIVE_LISTEN_MODE;\nnet/nfc/nci/core.c-289-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-291-\t\tcmd.disc_configs[cmd.num_disc_configs].rf_tech_and_mode =\nnet/nfc/nci/core.c:292:\t\t\tNCI_NFC_F_PASSIVE_LISTEN_MODE;\nnet/nfc/nci/core.c-293-\t\tcmd.disc_configs[cmd.num_disc_configs].frequency = 1;\n--\nnet/nfc/nci/core.c-296-\nnet/nfc/nci/core.c:297:\tnci_send_cmd(ndev, NCI_OP_RF_DISCOVER_CMD,\nnet/nfc/nci/core.c-298-\t\t (1 + (cmd.num_disc_configs * sizeof(struct disc_config))),\n--\nnet/nfc/nci/core.c=307=static void nci_rf_discover_select_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-315-\tswitch (cmd.rf_protocol) {\nnet/nfc/nci/core.c:316:\tcase NCI_RF_PROTOCOL_ISO_DEP:\nnet/nfc/nci/core.c:317:\t\tcmd.rf_interface = NCI_RF_INTERFACE_ISO_DEP;\nnet/nfc/nci/core.c-318-\t\tbreak;\nnet/nfc/nci/core.c-319-\nnet/nfc/nci/core.c:320:\tcase NCI_RF_PROTOCOL_NFC_DEP:\nnet/nfc/nci/core.c:321:\t\tcmd.rf_interface = NCI_RF_INTERFACE_NFC_DEP;\nnet/nfc/nci/core.c-322-\t\tbreak;\n--\nnet/nfc/nci/core.c-324-\tdefault:\nnet/nfc/nci/core.c:325:\t\tcmd.rf_interface = NCI_RF_INTERFACE_FRAME;\nnet/nfc/nci/core.c-326-\t\tbreak;\n--\nnet/nfc/nci/core.c-328-\nnet/nfc/nci/core.c:329:\tnci_send_cmd(ndev, NCI_OP_RF_DISCOVER_SELECT_CMD,\nnet/nfc/nci/core.c-330-\t\t sizeof(struct nci_rf_discover_select_cmd), \u0026cmd);\n--\nnet/nfc/nci/core.c=333=static void nci_rf_deactivate_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-338-\nnet/nfc/nci/core.c:339:\tnci_send_cmd(ndev, NCI_OP_RF_DEACTIVATE_CMD,\nnet/nfc/nci/core.c-340-\t\t sizeof(struct nci_rf_deactivate_cmd), \u0026cmd);\n--\nnet/nfc/nci/core.c=356=int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t len, const __u8 *payload)\n--\nnet/nfc/nci/core.c-359-\nnet/nfc/nci/core.c:360:\tparam.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY, oid);\nnet/nfc/nci/core.c-361-\tparam.len = len;\n--\nnet/nfc/nci/core.c-364-\treturn __nci_request(ndev, nci_generic_req, \u0026param,\nnet/nfc/nci/core.c:365:\t\t\t msecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-366-}\n--\nnet/nfc/nci/core.c=369=int nci_core_cmd(struct nci_dev *ndev, __u16 opcode, size_t len,\n--\nnet/nfc/nci/core.c-378-\treturn __nci_request(ndev, nci_generic_req, \u0026param,\nnet/nfc/nci/core.c:379:\t\t\t msecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-380-}\n--\nnet/nfc/nci/core.c=383=int nci_core_reset(struct nci_dev *ndev)\n--\nnet/nfc/nci/core.c-385-\treturn __nci_request(ndev, nci_reset_req, (void *)0,\nnet/nfc/nci/core.c:386:\t\t\t msecs_to_jiffies(NCI_RESET_TIMEOUT));\nnet/nfc/nci/core.c-387-}\n--\nnet/nfc/nci/core.c=390=int nci_core_init(struct nci_dev *ndev)\n--\nnet/nfc/nci/core.c-392-\treturn __nci_request(ndev, nci_init_req, (void *)0,\nnet/nfc/nci/core.c:393:\t\t\t msecs_to_jiffies(NCI_INIT_TIMEOUT));\nnet/nfc/nci/core.c-394-}\n--\nnet/nfc/nci/core.c=409=static void nci_nfcc_loopback_cb(void *context, struct sk_buff *skb, int err)\n--\nnet/nfc/nci/core.c-415-\tif (!conn_info) {\nnet/nfc/nci/core.c:416:\t\tnci_req_complete(ndev, NCI_STATUS_REJECTED);\nnet/nfc/nci/core.c-417-\t\treturn;\n--\nnet/nfc/nci/core.c-421-\nnet/nfc/nci/core.c:422:\tnci_req_complete(ndev, NCI_STATUS_OK);\nnet/nfc/nci/core.c-423-}\n--\nnet/nfc/nci/core.c=425=int nci_nfcc_loopback(struct nci_dev *ndev, const void *data, size_t data_len,\n--\nnet/nfc/nci/core.c-432-\tint conn_id = nci_get_conn_info_by_dest_type_params(ndev,\nnet/nfc/nci/core.c:433:\t\t\t\t\tNCI_DESTINATION_NFCC_LOOPBACK, NULL);\nnet/nfc/nci/core.c-434-\nnet/nfc/nci/core.c-435-\tif (conn_id \u003c 0) {\nnet/nfc/nci/core.c:436:\t\tr = nci_core_conn_create(ndev, NCI_DESTINATION_NFCC_LOOPBACK,\nnet/nfc/nci/core.c-437-\t\t\t\t\t 0, 0, NULL);\nnet/nfc/nci/core.c:438:\t\tif (r != NCI_STATUS_OK)\nnet/nfc/nci/core.c-439-\t\t\treturn r;\n--\nnet/nfc/nci/core.c-441-\t\tconn_id = nci_get_conn_info_by_dest_type_params(ndev,\nnet/nfc/nci/core.c:442:\t\t\t\t\tNCI_DESTINATION_NFCC_LOOPBACK,\nnet/nfc/nci/core.c-443-\t\t\t\t\tNULL);\n--\nnet/nfc/nci/core.c-453-\nnet/nfc/nci/core.c:454:\tskb = nci_skb_alloc(ndev, NCI_DATA_HDR_SIZE + data_len, GFP_KERNEL);\nnet/nfc/nci/core.c-455-\tif (!skb)\n--\nnet/nfc/nci/core.c-457-\nnet/nfc/nci/core.c:458:\tskb_reserve(skb, NCI_DATA_HDR_SIZE);\nnet/nfc/nci/core.c-459-\tskb_put_data(skb, data, data_len);\n--\nnet/nfc/nci/core.c-465-\tr = nci_request(ndev, nci_send_data_req, \u0026loopback_data,\nnet/nfc/nci/core.c:466:\t\t\tmsecs_to_jiffies(NCI_DATA_TIMEOUT));\nnet/nfc/nci/core.c:467:\tif (r == NCI_STATUS_OK \u0026\u0026 resp)\nnet/nfc/nci/core.c-468-\t\t*resp = conn_info-\u003erx_skb;\n--\nnet/nfc/nci/core.c=474=static int nci_open_device(struct nci_dev *ndev)\n--\nnet/nfc/nci/core.c-479-\nnet/nfc/nci/core.c:480:\tif (test_bit(NCI_UNREG, \u0026ndev-\u003eflags)) {\nnet/nfc/nci/core.c-481-\t\trc = -ENODEV;\n--\nnet/nfc/nci/core.c-484-\nnet/nfc/nci/core.c:485:\tif (test_bit(NCI_UP, \u0026ndev-\u003eflags)) {\nnet/nfc/nci/core.c-486-\t\trc = -EALREADY;\n--\nnet/nfc/nci/core.c-496-\nnet/nfc/nci/core.c:497:\tset_bit(NCI_INIT, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-498-\n--\nnet/nfc/nci/core.c-503-\t\trc = __nci_request(ndev, nci_reset_req, (void *)0,\nnet/nfc/nci/core.c:504:\t\t\t\t msecs_to_jiffies(NCI_RESET_TIMEOUT));\nnet/nfc/nci/core.c-505-\t}\n--\nnet/nfc/nci/core.c-512-\t\tstruct nci_core_init_v2_cmd nci_init_v2_cmd = {\nnet/nfc/nci/core.c:513:\t\t\t.feature1 = NCI_FEATURE_DISABLE,\nnet/nfc/nci/core.c:514:\t\t\t.feature2 = NCI_FEATURE_DISABLE\nnet/nfc/nci/core.c-515-\t\t};\n--\nnet/nfc/nci/core.c-517-\nnet/nfc/nci/core.c:518:\t\tif (ndev-\u003enci_ver \u0026 NCI_VER_2_MASK)\nnet/nfc/nci/core.c-519-\t\t\topt = \u0026nci_init_v2_cmd;\n--\nnet/nfc/nci/core.c-521-\t\trc = __nci_request(ndev, nci_init_req, opt,\nnet/nfc/nci/core.c:522:\t\t\t\t msecs_to_jiffies(NCI_INIT_TIMEOUT));\nnet/nfc/nci/core.c-523-\t}\n--\nnet/nfc/nci/core.c-529-\t\trc = __nci_request(ndev, nci_init_complete_req, (void *)0,\nnet/nfc/nci/core.c:530:\t\t\t\t msecs_to_jiffies(NCI_INIT_TIMEOUT));\nnet/nfc/nci/core.c-531-\t}\nnet/nfc/nci/core.c-532-\nnet/nfc/nci/core.c:533:\tclear_bit(NCI_INIT, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-534-\nnet/nfc/nci/core.c-535-\tif (!rc) {\nnet/nfc/nci/core.c:536:\t\tset_bit(NCI_UP, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-537-\t\tnci_clear_target_list(ndev);\nnet/nfc/nci/core.c:538:\t\tatomic_set(\u0026ndev-\u003estate, NCI_IDLE);\nnet/nfc/nci/core.c-539-\t} else {\n--\nnet/nfc/nci/core.c-545-\t\tndev-\u003eops-\u003eclose(ndev);\nnet/nfc/nci/core.c:546:\t\tndev-\u003eflags \u0026= BIT(NCI_UNREG);\nnet/nfc/nci/core.c-547-\t}\n--\nnet/nfc/nci/core.c=554=static int nci_close_device(struct nci_dev *ndev)\n--\nnet/nfc/nci/core.c-562-\nnet/nfc/nci/core.c:563:\tif (!test_and_clear_bit(NCI_UP, \u0026ndev-\u003eflags)) {\nnet/nfc/nci/core.c-564-\t\t/* Need to flush the cmd wq in case\n--\nnet/nfc/nci/core.c-569-\t\ttimer_delete_sync(\u0026ndev-\u003edata_timer);\nnet/nfc/nci/core.c:570:\t\tif (test_bit(NCI_DATA_EXCHANGE, \u0026ndev-\u003eflags))\nnet/nfc/nci/core.c-571-\t\t\tnci_data_exchange_complete(ndev, NULL,\n--\nnet/nfc/nci/core.c-588-\nnet/nfc/nci/core.c:589:\tset_bit(NCI_INIT, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-590-\t__nci_request(ndev, nci_reset_req, (void *)0,\nnet/nfc/nci/core.c:591:\t\t msecs_to_jiffies(NCI_RESET_TIMEOUT));\nnet/nfc/nci/core.c-592-\nnet/nfc/nci/core.c-593-\t/* After this point our queues are empty\nnet/nfc/nci/core.c:594:\t * rx work may be running but will see that NCI_UP was cleared\nnet/nfc/nci/core.c-595-\t */\n--\nnet/nfc/nci/core.c-597-\nnet/nfc/nci/core.c:598:\tclear_bit(NCI_INIT, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-599-\n--\nnet/nfc/nci/core.c-605-\nnet/nfc/nci/core.c:606:\tif (test_bit(NCI_DATA_EXCHANGE, \u0026ndev-\u003eflags))\nnet/nfc/nci/core.c-607-\t\tnci_data_exchange_complete(ndev, NULL, ndev-\u003ecur_conn_id,\n--\nnet/nfc/nci/core.c-609-\nnet/nfc/nci/core.c:610:\t/* Clear flags except NCI_UNREG */\nnet/nfc/nci/core.c:611:\tndev-\u003eflags \u0026= BIT(NCI_UNREG);\nnet/nfc/nci/core.c-612-\n--\nnet/nfc/nci/core.c-620-\nnet/nfc/nci/core.c:621:/* NCI command timer function */\nnet/nfc/nci/core.c-622-static void nci_cmd_timer(struct timer_list *t)\n--\nnet/nfc/nci/core.c-629-\nnet/nfc/nci/core.c:630:/* NCI data exchange timer function */\nnet/nfc/nci/core.c-631-static void nci_data_timer(struct timer_list *t)\n--\nnet/nfc/nci/core.c-634-\nnet/nfc/nci/core.c:635:\tset_bit(NCI_DATA_EXCHANGE_TO, \u0026ndev-\u003eflags);\nnet/nfc/nci/core.c-636-\tqueue_work(ndev-\u003erx_wq, \u0026ndev-\u003erx_work);\n--\nnet/nfc/nci/core.c=653=int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, const __u8 *val)\n--\nnet/nfc/nci/core.c-664-\treturn __nci_request(ndev, nci_set_config_req, \u0026param,\nnet/nfc/nci/core.c:665:\t\t\t msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));\nnet/nfc/nci/core.c-666-}\n--\nnet/nfc/nci/core.c=669=static void nci_nfcee_discover_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-675-\nnet/nfc/nci/core.c:676:\tnci_send_cmd(ndev, NCI_OP_NFCEE_DISCOVER_CMD, 1, \u0026cmd);\nnet/nfc/nci/core.c-677-}\n--\nnet/nfc/nci/core.c=679=int nci_nfcee_discover(struct nci_dev *ndev, u8 action)\n--\nnet/nfc/nci/core.c-683-\treturn __nci_request(ndev, nci_nfcee_discover_req, (void *)opt,\nnet/nfc/nci/core.c:684:\t\t\t\tmsecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-685-}\n--\nnet/nfc/nci/core.c=688=static void nci_nfcee_mode_set_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-691-\nnet/nfc/nci/core.c:692:\tnci_send_cmd(ndev, NCI_OP_NFCEE_MODE_SET_CMD,\nnet/nfc/nci/core.c-693-\t\t sizeof(struct nci_nfcee_mode_set_cmd), cmd);\n--\nnet/nfc/nci/core.c=696=int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode)\n--\nnet/nfc/nci/core.c-703-\treturn __nci_request(ndev, nci_nfcee_mode_set_req, \u0026cmd,\nnet/nfc/nci/core.c:704:\t\t\t msecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-705-}\n--\nnet/nfc/nci/core.c=708=static void nci_core_conn_create_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-711-\nnet/nfc/nci/core.c:712:\tnci_send_cmd(ndev, NCI_OP_CORE_CONN_CREATE_CMD, data-\u003elength, data-\u003ecmd);\nnet/nfc/nci/core.c-713-}\n--\nnet/nfc/nci/core.c=715=int nci_core_conn_create(struct nci_dev *ndev, u8 destination_type,\n--\nnet/nfc/nci/core.c-747-\tr = __nci_request(ndev, nci_core_conn_create_req, \u0026data,\nnet/nfc/nci/core.c:748:\t\t\t msecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-749-\tkfree(cmd);\n--\nnet/nfc/nci/core.c=754=static void nci_core_conn_close_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-757-\nnet/nfc/nci/core.c:758:\tnci_send_cmd(ndev, NCI_OP_CORE_CONN_CLOSE_CMD, 1, \u0026conn_id);\nnet/nfc/nci/core.c-759-}\n--\nnet/nfc/nci/core.c=761=int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id)\n--\nnet/nfc/nci/core.c-766-\treturn __nci_request(ndev, nci_core_conn_close_req, (void *)opt,\nnet/nfc/nci/core.c:767:\t\t\t msecs_to_jiffies(NCI_CMD_TIMEOUT));\nnet/nfc/nci/core.c-768-}\n--\nnet/nfc/nci/core.c=779=static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)\n--\nnet/nfc/nci/core.c-791-\nnet/nfc/nci/core.c:792:\tparam.id = NCI_PN_ATR_REQ_GEN_BYTES;\nnet/nfc/nci/core.c-793-\nnet/nfc/nci/core.c-794-\trc = nci_request(ndev, nci_set_config_req, \u0026param,\nnet/nfc/nci/core.c:795:\t\t\t msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));\nnet/nfc/nci/core.c-796-\tif (rc)\n--\nnet/nfc/nci/core.c-798-\nnet/nfc/nci/core.c:799:\tparam.id = NCI_LN_ATR_RES_GEN_BYTES;\nnet/nfc/nci/core.c-800-\nnet/nfc/nci/core.c-801-\treturn nci_request(ndev, nci_set_config_req, \u0026param,\nnet/nfc/nci/core.c:802:\t\t\t msecs_to_jiffies(NCI_SET_CONFIG_TIMEOUT));\nnet/nfc/nci/core.c-803-}\n--\nnet/nfc/nci/core.c=805=static int nci_set_listen_parameters(struct nfc_dev *nfc_dev)\n--\nnet/nfc/nci/core.c-810-\nnet/nfc/nci/core.c:811:\tval = NCI_LA_SEL_INFO_NFC_DEP_MASK;\nnet/nfc/nci/core.c-812-\nnet/nfc/nci/core.c:813:\trc = nci_set_config(ndev, NCI_LA_SEL_INFO, 1, \u0026val);\nnet/nfc/nci/core.c-814-\tif (rc)\n--\nnet/nfc/nci/core.c-816-\nnet/nfc/nci/core.c:817:\tval = NCI_LF_PROTOCOL_TYPE_NFC_DEP_MASK;\nnet/nfc/nci/core.c-818-\nnet/nfc/nci/core.c:819:\trc = nci_set_config(ndev, NCI_LF_PROTOCOL_TYPE, 1, \u0026val);\nnet/nfc/nci/core.c-820-\tif (rc)\n--\nnet/nfc/nci/core.c-822-\nnet/nfc/nci/core.c:823:\tval = NCI_LF_CON_BITR_F_212 | NCI_LF_CON_BITR_F_424;\nnet/nfc/nci/core.c-824-\nnet/nfc/nci/core.c:825:\treturn nci_set_config(ndev, NCI_LF_CON_BITR_F, 1, \u0026val);\nnet/nfc/nci/core.c-826-}\n--\nnet/nfc/nci/core.c=828=static int nci_start_poll(struct nfc_dev *nfc_dev,\n--\nnet/nfc/nci/core.c-834-\nnet/nfc/nci/core.c:835:\tif ((atomic_read(\u0026ndev-\u003estate) == NCI_DISCOVERY) ||\nnet/nfc/nci/core.c:836:\t (atomic_read(\u0026ndev-\u003estate) == NCI_W4_ALL_DISCOVERIES)) {\nnet/nfc/nci/core.c-837-\t\tpr_err(\"unable to start poll, since poll is already active\\n\");\n--\nnet/nfc/nci/core.c-845-\nnet/nfc/nci/core.c:846:\tif ((atomic_read(\u0026ndev-\u003estate) == NCI_W4_HOST_SELECT) ||\nnet/nfc/nci/core.c:847:\t (atomic_read(\u0026ndev-\u003estate) == NCI_POLL_ACTIVE)) {\nnet/nfc/nci/core.c-848-\t\tpr_debug(\"target active or w4 select, implicitly deactivate\\n\");\n--\nnet/nfc/nci/core.c-850-\t\trc = nci_request(ndev, nci_rf_deactivate_req,\nnet/nfc/nci/core.c:851:\t\t\t\t (void *)NCI_DEACTIVATE_TYPE_IDLE_MODE,\nnet/nfc/nci/core.c:852:\t\t\t\t msecs_to_jiffies(NCI_RF_DEACTIVATE_TIMEOUT));\nnet/nfc/nci/core.c-853-\t\tif (rc)\n--\nnet/nfc/nci/core.c-873-\trc = nci_request(ndev, nci_rf_discover_req, \u0026param,\nnet/nfc/nci/core.c:874:\t\t\t msecs_to_jiffies(NCI_RF_DISC_TIMEOUT));\nnet/nfc/nci/core.c-875-\n--\nnet/nfc/nci/core.c=882=static void nci_stop_poll(struct nfc_dev *nfc_dev)\n--\nnet/nfc/nci/core.c-885-\nnet/nfc/nci/core.c:886:\tif ((atomic_read(\u0026ndev-\u003estate) != NCI_DISCOVERY) \u0026\u0026\nnet/nfc/nci/core.c:887:\t (atomic_read(\u0026ndev-\u003estate) != NCI_W4_ALL_DISCOVERIES)) {\nnet/nfc/nci/core.c-888-\t\tpr_err(\"unable to stop poll, since poll is not active\\n\");\n--\nnet/nfc/nci/core.c-892-\tnci_request(ndev, nci_rf_deactivate_req,\nnet/nfc/nci/core.c:893:\t\t (void *)NCI_DEACTIVATE_TYPE_IDLE_MODE,\nnet/nfc/nci/core.c:894:\t\t msecs_to_jiffies(NCI_RF_DEACTIVATE_TIMEOUT));\nnet/nfc/nci/core.c-895-}\n--\nnet/nfc/nci/core.c=897=static int nci_activate_target(struct nfc_dev *nfc_dev,\n--\nnet/nfc/nci/core.c-907-\nnet/nfc/nci/core.c:908:\tif ((atomic_read(\u0026ndev-\u003estate) != NCI_W4_HOST_SELECT) \u0026\u0026\nnet/nfc/nci/core.c:909:\t (atomic_read(\u0026ndev-\u003estate) != NCI_POLL_ACTIVE)) {\nnet/nfc/nci/core.c-910-\t\tpr_err(\"there is no available target to activate\\n\");\n--\nnet/nfc/nci/core.c-941-\nnet/nfc/nci/core.c:942:\tif (atomic_read(\u0026ndev-\u003estate) == NCI_W4_HOST_SELECT) {\nnet/nfc/nci/core.c-943-\t\tparam.rf_discovery_id = nci_target-\u003elogical_idx;\n--\nnet/nfc/nci/core.c-945-\t\tif (protocol == NFC_PROTO_JEWEL)\n\n"
} |
| 11/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 18533 output: 35 thoughts: 54 Thoughts: Here's my analysis of what's going on: **Kernel Module Dependency Check** Okay, so I'm looking at how the NFC NCI driver is built. My initial thought is that `net/nfc/nci/data.c` is the core source for the NCI implementation. I'm making a mental note that this code is either compiled as a kernel module named `nci.ko` or, depending on the kernel configuration, might be built directly into the kernel itself as `CONFIG_NFC_NCI`. The next step is clear – I need to dive into `net/nfc/nci/Makefile` to understand the build process and the dependency chain. I expect the Makefile to specify the compilation flags, dependencies, and conditions that determine whether `nci.ko` is created or the code is built-in. |
| 12/2 | 2026/09/21 00:42 | tool | read-file |
0mArgs:{
"File": "net/nfc/nci/Makefile",
"FirstLine": 1,
"LineCount": 20
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0\n 2:\t#\n 3:\t# Makefile for the Linux NFC NCI layer.\n 4:\t#\n 5:\t\n 6:\tobj-$(CONFIG_NFC_NCI) += nci.o\n 7:\t\n 8:\tnci-objs := core.o data.o lib.o ntf.o rsp.o hci.o\n 9:\t\n 10:\tnci_spi-y += spi.o\n 11:\tobj-$(CONFIG_NFC_NCI_SPI) += nci_spi.o\n 12:\t\n 13:\tnci_uart-y += uart.o\n 14:\tobj-$(CONFIG_NFC_NCI_UART) += nci_uart.o\n"
} |
| 13/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 19016 output: 27 thoughts: 99 Thoughts: **My Analysis of NFC/NCI Driver Dependencies** Okay, so I'm looking at this build setup, and the `nci-objs` variable immediately flags my attention. It seems to contain object files related to the NCI (NFC Controller Interface) protocol: `core.o`, `data.o`, `lib.o`, `ntf.o`, `rsp.o`, and `hci.o`. That's a solid set of core components. The critical thing here is the conditional inclusion based on `CONFIG_NFC_NCI` – which, of course, is dependent on `CONFIG_NFC` being enabled in the first place. That's standard practice, but it's important to keep the dependency chain in mind. Now, my mind starts to wander down the driver path. Since we're dealing with NCI, I need to understand which *drivers* are actually utilizing this interface or, perhaps, are virtual drivers of some kind. Are we looking at actual hardware implementations or is there something emulated in, say, QEMU? USB NFC drivers sometimes use an NCI-like structure, but those are just implemented differently. I need to make sure I am accounting for the virtual drivers as well, as they may be implemented using NCI. I'll need to check the selection and dependency relationships as well; I want to see which drivers are *selecting* or *depending* on `NFC_NCI`. This will give me a better picture of the ecosystem using this interface. It's all about following the breadcrumbs to understand the overall architecture. |
| 14/2 | 2026/09/21 00:42 | tool | grepper |
0mArgs:{
"Expression": "NFC_NCI",
"PathPrefix": "drivers/"
}Results: {
"Output": "drivers/nfc/Kconfig=52=config NFC_VIRTUAL_NCI\ndrivers/nfc/Kconfig-53-\ttristate \"NCI device simulator driver\"\ndrivers/nfc/Kconfig:54:\tdepends on NFC_NCI\ndrivers/nfc/Kconfig-55-\thelp\n--\ndrivers/nfc/fdp/Kconfig=2=config NFC_FDP\ndrivers/nfc/fdp/Kconfig-3-\ttristate \"Intel FDP NFC driver\"\ndrivers/nfc/fdp/Kconfig:4:\tdepends on NFC_NCI\ndrivers/nfc/fdp/Kconfig-5-\tselect CRC_CCITT\n--\ndrivers/nfc/nfcmrvl/Kconfig=10=config NFC_MRVL_USB\ndrivers/nfc/nfcmrvl/Kconfig-11-\ttristate \"Marvell NFC-over-USB driver\"\ndrivers/nfc/nfcmrvl/Kconfig:12:\tdepends on NFC_NCI \u0026\u0026 USB\ndrivers/nfc/nfcmrvl/Kconfig-13-\tselect NFC_MRVL\n--\ndrivers/nfc/nfcmrvl/Kconfig=23=config NFC_MRVL_UART\ndrivers/nfc/nfcmrvl/Kconfig-24-\ttristate \"Marvell NFC-over-UART driver\"\ndrivers/nfc/nfcmrvl/Kconfig:25:\tdepends on NFC_NCI \u0026\u0026 NFC_NCI_UART\ndrivers/nfc/nfcmrvl/Kconfig-26-\tselect NFC_MRVL\n--\ndrivers/nfc/nfcmrvl/Kconfig=46=config NFC_MRVL_SPI\ndrivers/nfc/nfcmrvl/Kconfig-47-\ttristate \"Marvell NFC-over-SPI driver\"\ndrivers/nfc/nfcmrvl/Kconfig:48:\tdepends on NFC_MRVL \u0026\u0026 NFC_NCI_SPI\ndrivers/nfc/nfcmrvl/Kconfig-49-\thelp\n--\ndrivers/nfc/nxp-nci/Kconfig=2=config NFC_NXP_NCI\ndrivers/nfc/nxp-nci/Kconfig-3-\ttristate \"NXP-NCI NFC driver\"\ndrivers/nfc/nxp-nci/Kconfig:4:\tdepends on NFC_NCI\ndrivers/nfc/nxp-nci/Kconfig-5-\thelp\n--\ndrivers/nfc/s3fwrn5/Kconfig=10=config NFC_S3FWRN5_I2C\ndrivers/nfc/s3fwrn5/Kconfig-11-\ttristate \"Samsung S3FWRN5 I2C support\"\ndrivers/nfc/s3fwrn5/Kconfig:12:\tdepends on NFC_NCI \u0026\u0026 I2C\ndrivers/nfc/s3fwrn5/Kconfig-13-\tselect NFC_S3FWRN5\n--\ndrivers/nfc/s3fwrn5/Kconfig=23=config NFC_S3FWRN82_UART\ndrivers/nfc/s3fwrn5/Kconfig-24- tristate \"Samsung S3FWRN82 UART support\"\ndrivers/nfc/s3fwrn5/Kconfig:25: depends on NFC_NCI \u0026\u0026 SERIAL_DEV_BUS\ndrivers/nfc/s3fwrn5/Kconfig-26- select NFC_S3FWRN5\n--\ndrivers/nfc/st-nci/Kconfig=9=config NFC_ST_NCI_I2C\ndrivers/nfc/st-nci/Kconfig-10-\ttristate \"STMicroelectronics ST NCI NFC driver (I2C)\"\ndrivers/nfc/st-nci/Kconfig:11:\tdepends on NFC_NCI \u0026\u0026 I2C\ndrivers/nfc/st-nci/Kconfig-12-\tselect NFC_ST_NCI\n--\ndrivers/nfc/st-nci/Kconfig=21=config NFC_ST_NCI_SPI\ndrivers/nfc/st-nci/Kconfig-22-\ttristate \"STMicroelectronics ST NCI NFC driver (SPI)\"\ndrivers/nfc/st-nci/Kconfig:23:\tdepends on NFC_NCI \u0026\u0026 SPI\ndrivers/nfc/st-nci/Kconfig-24-\tselect NFC_ST_NCI\n"
} |
| 15/2 | 2026/09/21 00:42 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 20563 output: 34 thoughts: 126 Thoughts: **Examining NFC Driver Dependencies** Okay, so I'm looking at this kernel configuration and immediately my brain hones in on some interesting NFC driver dependencies. First, I see `CONFIG_NFC_VIRTUAL_NCI`, the "NCI device simulator driver," which, unsurprisingly, is contingent on `NFC_NCI`. Makes perfect sense. No surprises there. But then, the `NFC_MRVL_USB` driver, the "Marvell NFC-over-USB driver," that's where things get more interesting. It *also* depends on `NFC_NCI`, but it adds the `USB` dependency on top of it. And right away, my internal radar pings – USB, NFC, and NCI, I'm thinking USB emulation, raw gadget modes, vhci, and usbip potentially coming into play here. These USB drivers are often used in interesting test scenarios. And then, lastly, `NFC_NCI_UART`: NCI over UART – that's signaling that we might be dealing with TTY line disciplines or even looking at something related to `syz_open_pts`. Always a good angle for fuzzing and testing. Right, let's take a closer look at that virtual NCI driver, `CONFIG_NFC_VIRTUAL_NCI`. I want to see what's really happening under the hood. It seems to be a good starting point for analysis. |
| 16/2 | 2026/09/21 00:43 | tool | read-file |
0mArgs:{
"File": "drivers/nfc/Kconfig",
"FirstLine": 50,
"LineCount": 20
}Results: {
"Contents": " 50:\t\t If unsure, say N.\n 51:\t\n 52:\tconfig NFC_VIRTUAL_NCI\n 53:\t\ttristate \"NCI device simulator driver\"\n 54:\t\tdepends on NFC_NCI\n 55:\t\thelp\n 56:\t\t NCI virtual device simulates a NCI device to the user.\n 57:\t\t It can be used to validate the NCI module and applications.\n 58:\t\t This driver supports communication between the virtual NCI device and\n 59:\t\t module.\n 60:\t\n 61:\t\t If unsure, say N.\n 62:\t\n 63:\tsource \"drivers/nfc/fdp/Kconfig\"\n 64:\tsource \"drivers/nfc/pn544/Kconfig\"\n 65:\tsource \"drivers/nfc/pn533/Kconfig\"\n 66:\tsource \"drivers/nfc/microread/Kconfig\"\n 67:\tsource \"drivers/nfc/nfcmrvl/Kconfig\"\n 68:\tsource \"drivers/nfc/st21nfca/Kconfig\"\n 69:\tsource \"drivers/nfc/st-nci/Kconfig\"\n"
} |
| 17/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 21349 output: 28 thoughts: 20 Thoughts: Here's my attempt at summarizing that thought process, tailored for an expert audience: **Diving into Virtual NFC Device Driver** Okay, so I need to understand the architecture of this virtual NFC device driver. My initial thought is to dive right into the code and see how `drivers/nfc/virtual_ncidev.c` is implemented. I want to see the key structures, how it handles communication, and what abstractions it employs. I'm expecting to find the standard kernel driver entry points – probe, remove, module_init/exit. I'm especially interested in how it interacts with the NFC core layer and emulates the hardware. Knowing the details of its data flow and interrupt handling is essential for understanding its functionality and potential performance bottlenecks. I am expecting it uses the standard NFC device interface and I'm curious what techniques it uses to make it appear as a physical device. I'll likely start by tracing a simple operation, like a card read, to follow the calls and understand the internal state changes. |
| 18/2 | 2026/09/21 00:43 | tool | grepper |
0mArgs:{
"Expression": "virtual_nci",
"PathPrefix": "drivers/nfc"
}Results: {
"Output": "drivers/nfc/Makefile=19=obj-$(CONFIG_NFC_ST95HF)\t+= st95hf/\ndrivers/nfc/Makefile:20:obj-$(CONFIG_NFC_VIRTUAL_NCI)\t+= virtual_ncidev.o\n--\ndrivers/nfc/virtual_ncidev.c-23-\ndrivers/nfc/virtual_ncidev.c:24:struct virtual_nci_dev {\ndrivers/nfc/virtual_ncidev.c-25-\tstruct nci_dev *ndev;\n--\ndrivers/nfc/virtual_ncidev.c-31-\ndrivers/nfc/virtual_ncidev.c:32:static int virtual_nci_open(struct nci_dev *ndev)\ndrivers/nfc/virtual_ncidev.c-33-{\ndrivers/nfc/virtual_ncidev.c:34:\tstruct virtual_nci_dev *vdev = nci_get_drvdata(ndev);\ndrivers/nfc/virtual_ncidev.c-35-\n--\ndrivers/nfc/virtual_ncidev.c-39-\ndrivers/nfc/virtual_ncidev.c:40:static int virtual_nci_close(struct nci_dev *ndev)\ndrivers/nfc/virtual_ncidev.c-41-{\ndrivers/nfc/virtual_ncidev.c:42:\tstruct virtual_nci_dev *vdev = nci_get_drvdata(ndev);\ndrivers/nfc/virtual_ncidev.c-43-\n--\ndrivers/nfc/virtual_ncidev.c-52-\ndrivers/nfc/virtual_ncidev.c:53:static int virtual_nci_send(struct nci_dev *ndev, struct sk_buff *skb)\ndrivers/nfc/virtual_ncidev.c-54-{\ndrivers/nfc/virtual_ncidev.c:55:\tstruct virtual_nci_dev *vdev = nci_get_drvdata(ndev);\ndrivers/nfc/virtual_ncidev.c-56-\n--\ndrivers/nfc/virtual_ncidev.c-75-\ndrivers/nfc/virtual_ncidev.c:76:static const struct nci_ops virtual_nci_ops = {\ndrivers/nfc/virtual_ncidev.c:77:\t.open = virtual_nci_open,\ndrivers/nfc/virtual_ncidev.c:78:\t.close = virtual_nci_close,\ndrivers/nfc/virtual_ncidev.c:79:\t.send = virtual_nci_send\ndrivers/nfc/virtual_ncidev.c-80-};\ndrivers/nfc/virtual_ncidev.c-81-\ndrivers/nfc/virtual_ncidev.c:82:static ssize_t virtual_ncidev_read(struct file *file, char __user *buf,\ndrivers/nfc/virtual_ncidev.c-83-\t\t\t\t size_t count, loff_t *ppos)\ndrivers/nfc/virtual_ncidev.c-84-{\ndrivers/nfc/virtual_ncidev.c:85:\tstruct virtual_nci_dev *vdev = file-\u003eprivate_data;\ndrivers/nfc/virtual_ncidev.c-86-\tsize_t actual_len;\n--\ndrivers/nfc/virtual_ncidev.c-112-\ndrivers/nfc/virtual_ncidev.c:113:static ssize_t virtual_ncidev_write(struct file *file,\ndrivers/nfc/virtual_ncidev.c-114-\t\t\t\t const char __user *buf,\n--\ndrivers/nfc/virtual_ncidev.c-116-{\ndrivers/nfc/virtual_ncidev.c:117:\tstruct virtual_nci_dev *vdev = file-\u003eprivate_data;\ndrivers/nfc/virtual_ncidev.c-118-\tstruct sk_buff *skb;\n--\ndrivers/nfc/virtual_ncidev.c-132-\ndrivers/nfc/virtual_ncidev.c:133:static int virtual_ncidev_open(struct inode *inode, struct file *file)\ndrivers/nfc/virtual_ncidev.c-134-{\ndrivers/nfc/virtual_ncidev.c-135-\tint ret = 0;\ndrivers/nfc/virtual_ncidev.c:136:\tstruct virtual_nci_dev *vdev;\ndrivers/nfc/virtual_ncidev.c-137-\n--\ndrivers/nfc/virtual_ncidev.c-140-\t\treturn -ENOMEM;\ndrivers/nfc/virtual_ncidev.c:141:\tvdev-\u003endev = nci_allocate_device(\u0026virtual_nci_ops,\ndrivers/nfc/virtual_ncidev.c-142-\t\tVIRTUAL_NFC_PROTOCOLS, 0, 0);\n--\ndrivers/nfc/virtual_ncidev.c-163-\ndrivers/nfc/virtual_ncidev.c:164:static int virtual_ncidev_close(struct inode *inode, struct file *file)\ndrivers/nfc/virtual_ncidev.c-165-{\ndrivers/nfc/virtual_ncidev.c:166:\tstruct virtual_nci_dev *vdev = file-\u003eprivate_data;\ndrivers/nfc/virtual_ncidev.c-167-\n--\ndrivers/nfc/virtual_ncidev.c-175-\ndrivers/nfc/virtual_ncidev.c:176:static long virtual_ncidev_ioctl(struct file *file, unsigned int cmd,\ndrivers/nfc/virtual_ncidev.c-177-\t\t\t\t unsigned long arg)\ndrivers/nfc/virtual_ncidev.c-178-{\ndrivers/nfc/virtual_ncidev.c:179:\tstruct virtual_nci_dev *vdev = file-\u003eprivate_data;\ndrivers/nfc/virtual_ncidev.c-180-\tconst struct nfc_dev *nfc_dev = vdev-\u003endev-\u003enfc_dev;\n--\ndrivers/nfc/virtual_ncidev.c-191-\ndrivers/nfc/virtual_ncidev.c:192:static const struct file_operations virtual_ncidev_fops = {\ndrivers/nfc/virtual_ncidev.c-193-\t.owner = THIS_MODULE,\ndrivers/nfc/virtual_ncidev.c:194:\t.read = virtual_ncidev_read,\ndrivers/nfc/virtual_ncidev.c:195:\t.write = virtual_ncidev_write,\ndrivers/nfc/virtual_ncidev.c:196:\t.open = virtual_ncidev_open,\ndrivers/nfc/virtual_ncidev.c:197:\t.release = virtual_ncidev_close,\ndrivers/nfc/virtual_ncidev.c:198:\t.unlocked_ioctl = virtual_ncidev_ioctl\ndrivers/nfc/virtual_ncidev.c-199-};\n--\ndrivers/nfc/virtual_ncidev.c=201=static struct miscdevice miscdev = {\ndrivers/nfc/virtual_ncidev.c-202-\t.minor = MISC_DYNAMIC_MINOR,\ndrivers/nfc/virtual_ncidev.c:203:\t.name = \"virtual_nci\",\ndrivers/nfc/virtual_ncidev.c:204:\t.fops = \u0026virtual_ncidev_fops,\ndrivers/nfc/virtual_ncidev.c-205-\t.mode = 0600,\n"
} |
| 19/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 23504 output: 39 thoughts: 902 Thoughts: **Analyzing NFC Data Transmission in the Linux Kernel** Okay, so I'm looking at how NFC data is handled, specifically within the `net/nfc/nci/data.c` file. It seems `virtual_nci` is a miscdevice, `/dev/virtual_nci`, and it's created by `CONFIG_NFC_VIRTUAL_NCI`. Interesting! Userspace can interact with it to emulate an NCI device by reading and writing packets to it. Syzkaller is known to target this, which makes it a potential point of interest for fuzzing. Also, it looks like USB NFC devices, like `nfc-mrvl` USB, can be emulated using Syzkaller's USB raw gadget functionality. And then there are NFC sockets (`AF_NFC`) and NFC netlink (`GENL_NFC`) to consider. Now, I was about to dive into syzkaller's specifics, like its `syzlang` descriptions, to see how it interacts with NFC and `virtual_nci`, but I'm reminded that I can't directly search those. That's fine; I know those are standard paths. I need to focus on what's accessible to me. Let's look more closely at the code patch, specifically around line 100 in `net/nfc/nci/data.c`. It's dealing with fragmenting and queuing data for transmission. It seems `nci_queue_tx_data_frags` is responsible for this. The code calculates `frag_len` based on `total_len` and `conn_info->max_pkt_payload_len`. Ah, I see a `READ_ONCE()` call now, using `max_len = READ_ONCE(conn_info->max_pkt_payload_len)`. It looks like it addresses a possible race condition, with a comment mentioning that the "rx workqueue may update the field concurrently", which makes sense. The code's now using `max_len` instead of `conn_info->max_pkt_payload_len` directly. Then, if `max_len` is zero, there's an `EPROTO` error returned. I need to understand what situations would lead to a zero value for `max_len` and if that's an area for further investigation. |
| 20/2 | 2026/09/21 00:43 | tool | read-file |
0mArgs:{
"File": "net/nfc/nci/data.c",
"FirstLine": 110,
"LineCount": 80
}Results: {
"Contents": " 110:\t\tpr_debug(\"conn_id 0x%x, total_len %d\\n\", conn_id, total_len);\n 111:\t\n 112:\t\tconn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);\n 113:\t\tif (!conn_info) {\n 114:\t\t\trc = -EPROTO;\n 115:\t\t\tgoto exit;\n 116:\t\t}\n 117:\t\n 118:\t\t/* the rx workqueue may update the field concurrently */\n 119:\t\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\n 120:\t\n 121:\t\tif (!max_len) {\n 122:\t\t\trc = -EPROTO;\n 123:\t\t\tgoto exit;\n 124:\t\t}\n 125:\t\n 126:\t\t__skb_queue_head_init(\u0026frags_q);\n 127:\t\n 128:\t\twhile (total_len) {\n 129:\t\t\tfrag_len = min_t(int, total_len, max_len);\n 130:\t\n 131:\t\t\tskb_frag = nci_skb_alloc(ndev,\n 132:\t\t\t\t\t\t (NCI_DATA_HDR_SIZE + frag_len),\n 133:\t\t\t\t\t\t GFP_ATOMIC);\n 134:\t\t\tif (skb_frag == NULL) {\n 135:\t\t\t\trc = -ENOMEM;\n 136:\t\t\t\tgoto free_exit;\n 137:\t\t\t}\n 138:\t\t\tskb_reserve(skb_frag, NCI_DATA_HDR_SIZE);\n 139:\t\n 140:\t\t\t/* first, copy the data */\n 141:\t\t\tskb_put_data(skb_frag, data, frag_len);\n 142:\t\n 143:\t\t\t/* second, set the header */\n 144:\t\t\tnci_push_data_hdr(ndev, conn_id, skb_frag,\n 145:\t\t\t\t\t ((total_len == frag_len) ?\n 146:\t\t\t\t\t (NCI_PBF_LAST) : (NCI_PBF_CONT)));\n 147:\t\n 148:\t\t\t__skb_queue_tail(\u0026frags_q, skb_frag);\n 149:\t\n 150:\t\t\tdata += frag_len;\n 151:\t\t\ttotal_len -= frag_len;\n 152:\t\n 153:\t\t\tpr_debug(\"frag_len %d, remaining total_len %d\\n\",\n 154:\t\t\t\t frag_len, total_len);\n 155:\t\t}\n 156:\t\n 157:\t\t/* queue all fragments atomically */\n 158:\t\tspin_lock_irqsave(\u0026ndev-\u003etx_q.lock, flags);\n 159:\t\n 160:\t\twhile ((skb_frag = __skb_dequeue(\u0026frags_q)) != NULL)\n 161:\t\t\t__skb_queue_tail(\u0026ndev-\u003etx_q, skb_frag);\n 162:\t\n 163:\t\tspin_unlock_irqrestore(\u0026ndev-\u003etx_q.lock, flags);\n 164:\t\n 165:\t\t/* free the original skb */\n 166:\t\tkfree_skb(skb);\n 167:\t\n 168:\t\tgoto exit;\n 169:\t\n 170:\tfree_exit:\n 171:\t\twhile ((skb_frag = __skb_dequeue(\u0026frags_q)) != NULL)\n 172:\t\t\tkfree_skb(skb_frag);\n 173:\t\n 174:\texit:\n 175:\t\treturn rc;\n 176:\t}\n 177:\t\n 178:\t/* Send NCI data */\n 179:\tint nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\n 180:\t{\n 181:\t\tconst struct nci_conn_info *conn_info;\n 182:\t\tint rc = 0;\n 183:\t\n 184:\t\tpr_debug(\"conn_id 0x%x, plen %d\\n\", conn_id, skb-\u003elen);\n 185:\t\n 186:\t\tconn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);\n 187:\t\tif (!conn_info) {\n 188:\t\t\trc = -EPROTO;\n 189:\t\t\tgoto free_exit;\n"
} |
| 21/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 26183 output: 31 thoughts: 59 Thoughts: **Analyzing the `nci_queue_tx_data_frags` Function** Okay, let's break this down. I see that `nci_queue_tx_data_frags` is called from within `nci_send_data`. My immediate concern is the `max_pkt_payload_len` variable. I need to understand where its value is set and how it's modified; understanding this is crucial for the overall flow and potential performance characteristics. Time to fire up the grep and hunt down all instances of `max_pkt_payload_len` to get the full picture. |
| 22/2 | 2026/09/21 00:43 | tool | grepper |
0mArgs:{
"Expression": "max_pkt_payload_len",
"PathPrefix": "net/nfc"
}Results: {
"Output": "net/nfc/nci/data.c=85=int nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id)\n--\nnet/nfc/nci/data.c-92-\nnet/nfc/nci/data.c:93:\treturn conn_info-\u003emax_pkt_payload_len;\nnet/nfc/nci/data.c-94-}\n--\nnet/nfc/nci/data.c=97=static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n--\nnet/nfc/nci/data.c-118-\t/* the rx workqueue may update the field concurrently */\nnet/nfc/nci/data.c:119:\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\nnet/nfc/nci/data.c-120-\n--\nnet/nfc/nci/data.c=179=int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\n--\nnet/nfc/nci/data.c-192-\t/* check if the packet need to be fragmented */\nnet/nfc/nci/data.c:193:\tif (skb-\u003elen \u003c= conn_info-\u003emax_pkt_payload_len) {\nnet/nfc/nci/data.c-194-\t\t/* no need to fragment packet */\n--\nnet/nfc/nci/hci.c=142=static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,\n--\nnet/nfc/nci/hci.c-155-\ti = 0;\nnet/nfc/nci/hci.c:156:\tskb = nci_skb_alloc(ndev, conn_info-\u003emax_pkt_payload_len +\nnet/nfc/nci/hci.c-157-\t\t\t NCI_DATA_HDR_SIZE, GFP_ATOMIC);\n--\nnet/nfc/nci/hci.c-165-\t\t/* If last packet add NCI_HFP_NO_CHAINING */\nnet/nfc/nci/hci.c:166:\t\tif (i + conn_info-\u003emax_pkt_payload_len -\nnet/nfc/nci/hci.c-167-\t\t (skb-\u003elen + 1) \u003e= data_len) {\n--\nnet/nfc/nci/hci.c-170-\t\t} else {\nnet/nfc/nci/hci.c:171:\t\t\tlen = conn_info-\u003emax_pkt_payload_len - skb-\u003elen - 1;\nnet/nfc/nci/hci.c-172-\t\t}\n--\nnet/nfc/nci/hci.c-186-\t\t\tskb = nci_skb_alloc(ndev,\nnet/nfc/nci/hci.c:187:\t\t\t\t\t conn_info-\u003emax_pkt_payload_len +\nnet/nfc/nci/hci.c-188-\t\t\t\t\t NCI_DATA_HDR_SIZE, GFP_ATOMIC);\n--\nnet/nfc/nci/ntf.c=709=static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/ntf.c-858-\nnet/nfc/nci/ntf.c:859:\t\tconn_info-\u003emax_pkt_payload_len = ntf.max_data_pkt_payload_size;\nnet/nfc/nci/ntf.c-860-\t\tconn_info-\u003einitial_num_credits = ntf.initial_num_credits;\n--\nnet/nfc/nci/rsp.c=305=static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/rsp.c-347-\t\tconn_info-\u003econn_id = rsp-\u003econn_id;\nnet/nfc/nci/rsp.c:348:\t\tconn_info-\u003emax_pkt_payload_len = rsp-\u003emax_ctrl_pkt_payload_len;\nnet/nfc/nci/rsp.c-349-\t\tatomic_set(\u0026conn_info-\u003ecredits_cnt, rsp-\u003ecredits_cnt);\n"
} |
| 23/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 27530 output: 33 thoughts: 881 Thoughts: **Analyzing the Patch for Fuzzing Worthiness** Okay, so I've been digging into this patch. I started by looking at `net/nfc/nci/ntf.c`. It seems like a notification packet related to RF interface activation, `nci_rf_intf_activated_ntf_packet`, is the key. The code was using `ntf.max_data_pkt_payload_size` to determine the maximum packet payload length, `conn_info->max_pkt_payload_len`. The original logic had a bug! If `ntf.max_data_pkt_payload_size` was zero (or concurrently updated), the calculation of `frag_len` could end up being zero, and an infinite loop would occur because `total_len` wouldn't be reduced. Also, there was a data race issue. The fix involves storing `READ_ONCE(conn_info->max_pkt_payload_len)` in a local variable `max_len` and checking if `max_len` is zero before proceeding, preventing the infinite loop and addressing the race condition. Good catch! Now, I'm thinking about whether this change is worth fuzzing. I'm going through the criteria: Is it reachable? Is it executable code? I've reviewed the sections on fuzzing reachability. The key takeaway is: is the code *reachable* in a standard virtualized environment? Is it executable? * **Reachability:** `net/nfc/nci/data.c` is part of the NFC subsystem, a networking protocol. Crucially, it's reachable via `CONFIG_NFC_NCI` and the virtual device `CONFIG_NFC_VIRTUAL_NCI`, as well as potentially via `CONFIG_NFC_MRVL_USB` (USB gadget) or even raw sockets/netlink/AF_NFC. This means it's definitely accessible in our typical fuzzing setups. * **Executability:** The patch modifies *logic*. It checks for a zero value, prevents an infinite loop, and uses `READ_ONCE` to avoid a race condition. It's not just a refactoring or a dead code removal. It touches *reachable* executable code. Given this, according to the criteria for `WorthFuzzing`, this is a clear **yes**. The patch affects reachable executable code within a core subsystem (networking in this case), and it introduces defensive checks. So, the modified code definitely warrants fuzzing. Now, I need to figure out what kernel configs are needed. Let's see what `net/nfc/Kconfig` tells me. I need to determine the `EnableConfigs` necessary to build and test this code. |
| 24/2 | 2026/09/21 00:43 | tool | read-file |
0mArgs:{
"File": "net/nfc/Kconfig",
"FirstLine": 1,
"LineCount": 40
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# NFC subsystem configuration\n 4:\t#\n 5:\t\n 6:\tmenuconfig NFC\n 7:\t\tdepends on RFKILL || !RFKILL\n 8:\t\ttristate \"NFC subsystem support\"\n 9:\t\tdefault n\n 10:\t\thelp\n 11:\t\t Say Y here if you want to build support for NFC (Near field\n 12:\t\t communication) devices.\n 13:\t\n 14:\t\t To compile this support as a module, choose M here: the module will\n 15:\t\t be called nfc.\n 16:\t\n 17:\tconfig NFC_DIGITAL\n 18:\t\tdepends on NFC\n 19:\t\tselect CRC_CCITT\n 20:\t\tselect CRC_ITU_T\n 21:\t\ttristate \"NFC Digital Protocol stack support\"\n 22:\t\tdefault n\n 23:\t\thelp\n 24:\t\t Say Y if you want to build NFC digital protocol stack support.\n 25:\t\t This is needed by NFC chipsets whose firmware only implement\n 26:\t\t the NFC analog layer.\n 27:\t\n 28:\t\t To compile this support as a module, choose M here: the module will\n 29:\t\t be called nfc_digital.\n 30:\t\n 31:\tsource \"net/nfc/nci/Kconfig\"\n 32:\tsource \"net/nfc/hci/Kconfig\"\n 33:\t\n 34:\tsource \"drivers/nfc/Kconfig\"\n"
} |
| 25/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 29447 output: 34 thoughts: 230 Thoughts: **Kernel Configuration for NFC Virtualization** Okay, let's circle back to that `net/nfc/nci/Kconfig` file. I need to make absolutely sure I've got this right for the syzkaller setup. Right, first things first: `config NFC_NCI` depends on `NFC`. Then the object list, that all looks correct. And then we have the line `obj-$(CONFIG_NFC_NCI) += nci.o`. Confirmed, so we need `NFC` and `NFC_NCI` enabled, of course. Now, for that virtual device driver. That's the key, isn't it? We need to be able to instantiate an NCI device in syzkaller without physical hardware. Ah, yes, here we are, `CONFIG_NFC_VIRTUAL_NCI`! Let me just double-check that... yep, `depends on NFC_NCI`. Perfect. So, to recap: we're looking at `NFC`, `NFC_NCI`, and `NFC_VIRTUAL_NCI` configs. That's the baseline. Just to be thorough, I should check the surrounding `net/nfc/Kconfig` file again. Let me see if there are any other related configs, such as `CONFIG_NFC_RAW_SOCK`, that might influence the setup. Gotta be absolutely certain I haven't missed anything crucial here. |
| 26/2 | 2026/09/21 00:43 | tool | read-file |
0mError:file net/nfc/Kconfig does not have line 41, it has only 34 lines Args: {
"File": "net/nfc/Kconfig",
"FirstLine": 41,
"LineCount": 40
}Results: {
"error": "file net/nfc/Kconfig does not have line 41, it has only 34 lines"
} |
| 27/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 30062 output: 26 thoughts: 16 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Diving into the NFC Configuration Landscape** Alright, let's get down to brass tacks. I'm taking a look at the NFC subsystem. The first thing I always do when I'm assessing a system like this is get a good overview of the configuration landscape. So, I'm going to quickly drill into the `net/nfc/` directory. That's usually the go-to spot for the core NFC network configuration files, the ones that dictate the basic architecture, default settings, and overall module behavior. I'm expecting to find the standard suspects: module definitions, maybe some device-specific options, and potentially some high-level policy definitions. My gut tells me I should also keep an eye out for any unusual additions or proprietary configurations; that can offer a peek into potential customizations or vendor-specific implementations. Knowing these base configs are going to be key to any deeper diagnosis I need to do. |
| 28/2 | 2026/09/21 00:43 | tool | grepper |
0mArgs:{
"Expression": "config ",
"PathPrefix": "net/nfc"
}Results: {
"Output": "net/nfc/Kconfig-5-\nnet/nfc/Kconfig:6:menuconfig NFC\nnet/nfc/Kconfig-7-\tdepends on RFKILL || !RFKILL\n--\nnet/nfc/Kconfig-16-\nnet/nfc/Kconfig:17:config NFC_DIGITAL\nnet/nfc/Kconfig-18-\tdepends on NFC\n--\nnet/nfc/hci/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\nnet/nfc/hci/Kconfig:2:config NFC_HCI\nnet/nfc/hci/Kconfig-3-\tdepends on NFC\n--\nnet/nfc/hci/Kconfig-10-\nnet/nfc/hci/Kconfig:11:config NFC_SHDLC\nnet/nfc/hci/Kconfig-12-\tdepends on NFC_HCI\n--\nnet/nfc/nci/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\nnet/nfc/nci/Kconfig:2:config NFC_NCI\nnet/nfc/nci/Kconfig-3-\tdepends on NFC\n--\nnet/nfc/nci/Kconfig-12-\nnet/nfc/nci/Kconfig:13:config NFC_NCI_SPI\nnet/nfc/nci/Kconfig-14-\tdepends on NFC_NCI \u0026\u0026 SPI\n--\nnet/nfc/nci/Kconfig-23-\nnet/nfc/nci/Kconfig:24:config NFC_NCI_UART\nnet/nfc/nci/Kconfig-25-\tdepends on NFC_NCI \u0026\u0026 TTY\n--\nnet/nfc/nci/core.c=180=static void nci_init_complete_req(struct nci_dev *ndev, const void *opt)\n--\nnet/nfc/nci/core.c-182-\tstruct nci_rf_disc_map_cmd cmd;\nnet/nfc/nci/core.c:183:\tstruct disc_map_config *cfg = cmd.mapping_configs;\nnet/nfc/nci/core.c-184-\t__u8 *num = \u0026cmd.num_mapping_configs;\n"
} |
| 29/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 30873 output: 33 thoughts: 13 Thoughts: Here's my take on the thought process, as if I were the one thinking it: **Diving into the NFC Kconfig** Alright, time to get to the heart of the matter. I need to understand how the NFC subsystem is configured. The best place to start, as always, is with the `Kconfig` file. That's where all the configuration options live, the build-time knobs that determine what gets included and excluded. I'll need to open `drivers/nfc/Kconfig` and give it a thorough once-over. Hopefully, it’s well-structured and documented, but even if it's not, I can piece together the dependencies and implications of each option. This is the foundation upon which everything else in the NFC stack depends, so understanding it completely is critical. Let's see what gems are hidden in there. |
| 30/2 | 2026/09/21 00:43 | tool | read-file |
0mArgs:{
"File": "drivers/nfc/Kconfig",
"FirstLine": 1,
"LineCount": 60
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# Near Field Communication (NFC) devices\n 4:\t#\n 5:\t\n 6:\tmenu \"Near Field Communication (NFC) devices\"\n 7:\t\tdepends on NFC\n 8:\t\n 9:\tconfig NFC_TRF7970A\n 10:\t\ttristate \"Texas Instruments TRF7970a NFC driver\"\n 11:\t\tdepends on SPI \u0026\u0026 NFC_DIGITAL \u0026\u0026 GPIOLIB\n 12:\t\thelp\n 13:\t\t This option enables the NFC driver for Texas Instruments' TRF7970a\n 14:\t\t device. Such device supports 5 different protocols: ISO14443A,\n 15:\t\t ISO14443B, FeLiCa, ISO15693 and ISO18000-3.\n 16:\t\n 17:\t\t Say Y here to compile support for TRF7970a into the kernel or\n 18:\t\t say M to compile it as a module. The module will be called\n 19:\t\t trf7970a.ko.\n 20:\t\n 21:\tconfig NFC_MEI_PHY\n 22:\t\ttristate \"MEI bus NFC device support\"\n 23:\t\tdepends on INTEL_MEI \u0026\u0026 NFC_HCI\n 24:\t\thelp\n 25:\t\t This adds support to use an mei bus nfc device. Select this if you\n 26:\t\t will use an HCI NFC driver for an NFC chip connected behind an\n 27:\t\t Intel's Management Engine chip.\n 28:\t\n 29:\t\t If unsure, say N.\n 30:\t\n 31:\tconfig NFC_SIM\n 32:\t\ttristate \"NFC hardware simulator driver\"\n 33:\t\tdepends on NFC_DIGITAL\n 34:\t\thelp\n 35:\t\t This driver declares two virtual NFC devices supporting NFC-DEP\n 36:\t\t protocol. An LLCP connection can be established between them and\n 37:\t\t all packets sent from one device is sent back to the other, acting as\n 38:\t\t loopback devices.\n 39:\t\n 40:\t\t If unsure, say N.\n 41:\t\n 42:\tconfig NFC_PORT100\n 43:\t\ttristate \"Sony NFC Port-100 Series USB device support\"\n 44:\t\tdepends on USB\n 45:\t\tdepends on NFC_DIGITAL\n 46:\t\thelp\n 47:\t\t This adds support for Sony Port-100 chip based USB devices such as the\n 48:\t\t RC-S380 dongle.\n 49:\t\n 50:\t\t If unsure, say N.\n 51:\t\n 52:\tconfig NFC_VIRTUAL_NCI\n 53:\t\ttristate \"NCI device simulator driver\"\n 54:\t\tdepends on NFC_NCI\n 55:\t\thelp\n 56:\t\t NCI virtual device simulates a NCI device to the user.\n 57:\t\t It can be used to validate the NCI module and applications.\n 58:\t\t This driver supports communication between the virtual NCI device and\n 59:\t\t module.\n 60:\t\n"
} |
| 31/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 31943 output: 30 thoughts: 668 Thoughts: **My Analysis of NFC Configuration and Function Calls** Okay, so I'm diving into this NFC code. First, I need to figure out the essential configurations. It looks like `CONFIG_NFC_VIRTUAL_NCI` depends on `CONFIG_NFC_NCI`, which in turn depends on `CONFIG_NFC`. Simple enough. I should probably enable those three: "NFC", "NFC_NCI", and "NFC_VIRTUAL_NCI". Just to be thorough, I'll quickly check `CONFIG_NFC_MRVL_USB` – ah, yes, that one depends on "NFC_NCI && USB". Got it. Now, let's get into the function side of things, specifically `nci_queue_tx_data_frags`. My gut tells me this one might be inlined. I remember seeing it somewhere, so I need to check the declaration in `net/nfc/nci/data.c`. Okay, here it is: `static int nci_queue_tx_data_frags(...)`. Yup, it's static. That makes me think it's ripe for inlining. Let's see where it's called. Hmm, looks like it's only called within `nci_send_data`. And `nci_send_data` is `EXPORT_SYMBOL`ed, so it's definitely accessible externally. Given that `nci_queue_tx_data_frags` is static and only called once, the compiler *might* inline it. So, I need to cover my bases. According to the guidelines, I need to "List functions that specifically implement the logic being added or altered, or direct API entrypoints for the subsystem feature under review." Even though it might be inlined, I'm going to include both `nci_queue_tx_data_frags` and `nci_send_data` in my list. Safety first. Now, I should consider the callers of `nci_send_data` as well. Let's see... it's called by `nci_send_data_req` (which is part of `nci_nfcc_loopback`), `nci_transceive`, `nci_tm_send`, and `nci_hci_send_data`. I'll also need to investigate the callers of `nci_transceive` and `nci_tm_send` for a complete picture. |
| 32/2 | 2026/09/21 00:43 | tool | grepper |
0mArgs:{
"Expression": "nci_transceive",
"PathPrefix": "net/nfc"
}Results: {
"Output": "net/nfc/nci/core.c=1017=static int nci_dep_link_down(struct nfc_dev *nfc_dev)\n--\nnet/nfc/nci/core.c-1039-\nnet/nfc/nci/core.c:1040:static int nci_transceive(struct nfc_dev *nfc_dev, struct nfc_target *target,\nnet/nfc/nci/core.c-1041-\t\t\t struct sk_buff *skb,\n--\nnet/nfc/nci/core.c=1149=static const struct nfc_ops nci_nfc_ops = {\n--\nnet/nfc/nci/core.c-1157-\t.deactivate_target = nci_deactivate_target,\nnet/nfc/nci/core.c:1158:\t.im_transceive = nci_transceive,\nnet/nfc/nci/core.c-1159-\t.tm_send = nci_tm_send,\n"
} |
| 33/2 | 2026/09/21 00:43 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 33462 output: 205 thoughts: 447 Thoughts: **My Analysis of the NCI Patch** Okay, so I've been dissecting this patch and here's what I've gathered. It looks like `nci_transceive` is effectively mapped to `.im_transceive` within the `nci_nfc_ops` structure, and `nci_tm_send` corresponds to `.tm_send`. `nci_send_data` is the exported function at the NCI layer, and the key function modified by the patch seems to be `nci_queue_tx_data_frags`. My initial check confirms the primary touchpoint is `net/nfc/nci/data.c`, specifically `nci_queue_tx_data_frags`. This aligns perfectly with the focus symbols identified. Diving deeper, the core of this patch seems to address a potential race condition in `nci_queue_tx_data_frags()`. The `conn_info->max_pkt_payload_len` variable can be updated concurrently by the RX workqueue – situations like RF interface activation or connection responses. The fix uses `READ_ONCE()` to safeguard the value by reading it once into a local variable, `max_len`, and now includes a defensive check for `!max_len` to prevent an infinite fragmentation loop if `max_pkt_payload_len` becomes zero. Smart. Because this code resides within the NCI core networking layer, it’s relevant in several contexts – virtualized environments through virtual NCI devices (like `/dev/virtual_nci` enabled by `CONFIG_NFC_VIRTUAL_NCI`), USB NFC drivers, and even NFC user sockets. Thus, this is definitely reachable kernel logic. Given this scope and the potential race condition addressed, it's definitely a fuzzing target. Finally, I've confirmed the necessary configuration requirements are met: `CONFIG_NFC`, `CONFIG_NFC_NCI`, and `CONFIG_NFC_VIRTUAL_NCI` are all present. Everything checks out. I'm ready to call `set-results`. |
| 34/2 | 2026/09/21 00:43 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"NFC",
"NFC_NCI",
"NFC_VIRTUAL_NCI"
],
"FocusSymbols": [
"nci_queue_tx_data_frags",
"nci_send_data"
],
"Reasoning": "The patch modifies nci_queue_tx_data_frags() in net/nfc/nci/data.c to read conn_info-\u003emax_pkt_payload_len once using READ_ONCE() and validate that max_len is non-zero, preventing an infinite fragmentation loop or data race with concurrent rx updates. This logic is part of the NFC/NCI stack and is reachable in virtualized environments via virtual NCI devices (CONFIG_NFC_VIRTUAL_NCI), emulated USB NFC devices, and AF_NFC sockets. Therefore, it is worth fuzzing.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"NFC",
"NFC_NCI",
"NFC_VIRTUAL_NCI"
],
"FocusSymbols": [
"nci_queue_tx_data_frags",
"nci_send_data"
],
"Reasoning": "The patch modifies nci_queue_tx_data_frags() in net/nfc/nci/data.c to read conn_info-\u003emax_pkt_payload_len once using READ_ONCE() and validate that max_len is non-zero, preventing an infinite fragmentation loop or data race with concurrent rx updates. This logic is part of the NFC/NCI stack and is reachable in virtualized environments via virtual NCI devices (CONFIG_NFC_VIRTUAL_NCI), emulated USB NFC devices, and AF_NFC sockets. Therefore, it is worth fuzzing.",
"WorthFuzzing": true
} |
| 35/1 | 2026/09/21 00:43 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 36/2 | 2026/09/21 00:43 | agent | kmsan-evaluator |
0mModel:core Args: null Results: {
"KMSANReasoning": "The patch addresses a concurrency and infinite loop issue in `nci_queue_tx_data_frags` by capturing `conn_info-\u003emax_pkt_payload_len` with `READ_ONCE()` into a local variable `max_len` and validating that `max_len` is non-zero before chunking outgoing packets.\n\nThis modification does not touch any uninitialized stack or heap allocations, does not copy kernel memory to user space, and does not alter buffer bounds in a manner that could expose uninitialized memory. The underlying issue is an infinite loop / hung task and a data race, which fall under standard kernel testing / KCSAN / lockup detectors, rather than uninitialized memory access detectable by KMSAN. Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Instruction: You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.
CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
a comprehensive suite of debugging tools and sanitizers, including KASAN
(out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
(locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
or page allocations) and kernel-to-user memory info-leaks.
Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.
Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.
Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
attributes, ioctl output arguments, socket options, or BPF buffers) where fields
or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
uninitialized bytes of existing buffers.
Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
dereferences, locking deadlocks, or use-after-free bugs (these are already caught
by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.
Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit f406106506b247b86cd0c084060b96e1bc8ac280
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 21 00:42:26 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 4253edea5c8db..eeb5260c5d676 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -104,6 +104,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
struct sk_buff_head frags_q;
struct sk_buff *skb_frag;
int frag_len;
+ u8 max_len;
int rc = 0;
pr_debug("conn_id 0x%x, total_len %d\n", conn_id, total_len);
@@ -114,11 +115,18 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
goto exit;
}
+ /* the rx workqueue may update the field concurrently */
+ max_len = READ_ONCE(conn_info->max_pkt_payload_len);
+
+ if (!max_len) {
+ rc = -EPROTO;
+ goto exit;
+ }
+
__skb_queue_head_init(&frags_q);
while (total_len) {
- frag_len =
- min_t(int, total_len, conn_info->max_pkt_payload_len);
+ frag_len = min_t(int, total_len, max_len);
skb_frag = nci_skb_alloc(ndev,
(NCI_DATA_HDR_SIZE + frag_len),
|
| 37/3 | 2026/09/21 00:43 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 2336 output: 38 thoughts: 78 Thoughts: **Evaluating the Necessity of a KMSAN Fuzzing Session** Okay, so I need to decide if this patch series warrants a dedicated KMSAN fuzzing run. Let's break this down. The first step is always to analyze the patch itself, to understand the scope of the changes. The mention of `net/nfc/nci/data.c` immediately grabs my attention. NFC is always a good target. Now, I need to get a better handle on what's going on within that particular file. Let me check around line 104 in `net/nfc/nci/data.c` to see if there's anything interesting. I'll use `read-file` or `grepper`, depending on what's readily available to me, and take a quick look to identify any likely areas where memory safety might be an issue. Let's see if there's any allocation or deallocation activity, pointer manipulation, or anything that jumps out as a potential KMSAN target. |
| 38/3 | 2026/09/21 00:43 | tool | read-file |
0mArgs:{
"File": "net/nfc/nci/data.c",
"FirstLine": 95,
"LineCount": 70
}Results: {
"Contents": " 95:\tEXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);\n 96:\t\n 97:\tstatic int nci_queue_tx_data_frags(struct nci_dev *ndev,\n 98:\t\t\t\t\t __u8 conn_id,\n 99:\t\t\t\t\t struct sk_buff *skb) {\n 100:\t\tconst struct nci_conn_info *conn_info;\n 101:\t\tint total_len = skb-\u003elen;\n 102:\t\tconst unsigned char *data = skb-\u003edata;\n 103:\t\tunsigned long flags;\n 104:\t\tstruct sk_buff_head frags_q;\n 105:\t\tstruct sk_buff *skb_frag;\n 106:\t\tint frag_len;\n 107:\t\tu8 max_len;\n 108:\t\tint rc = 0;\n 109:\t\n 110:\t\tpr_debug(\"conn_id 0x%x, total_len %d\\n\", conn_id, total_len);\n 111:\t\n 112:\t\tconn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);\n 113:\t\tif (!conn_info) {\n 114:\t\t\trc = -EPROTO;\n 115:\t\t\tgoto exit;\n 116:\t\t}\n 117:\t\n 118:\t\t/* the rx workqueue may update the field concurrently */\n 119:\t\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\n 120:\t\n 121:\t\tif (!max_len) {\n 122:\t\t\trc = -EPROTO;\n 123:\t\t\tgoto exit;\n 124:\t\t}\n 125:\t\n 126:\t\t__skb_queue_head_init(\u0026frags_q);\n 127:\t\n 128:\t\twhile (total_len) {\n 129:\t\t\tfrag_len = min_t(int, total_len, max_len);\n 130:\t\n 131:\t\t\tskb_frag = nci_skb_alloc(ndev,\n 132:\t\t\t\t\t\t (NCI_DATA_HDR_SIZE + frag_len),\n 133:\t\t\t\t\t\t GFP_ATOMIC);\n 134:\t\t\tif (skb_frag == NULL) {\n 135:\t\t\t\trc = -ENOMEM;\n 136:\t\t\t\tgoto free_exit;\n 137:\t\t\t}\n 138:\t\t\tskb_reserve(skb_frag, NCI_DATA_HDR_SIZE);\n 139:\t\n 140:\t\t\t/* first, copy the data */\n 141:\t\t\tskb_put_data(skb_frag, data, frag_len);\n 142:\t\n 143:\t\t\t/* second, set the header */\n 144:\t\t\tnci_push_data_hdr(ndev, conn_id, skb_frag,\n 145:\t\t\t\t\t ((total_len == frag_len) ?\n 146:\t\t\t\t\t (NCI_PBF_LAST) : (NCI_PBF_CONT)));\n 147:\t\n 148:\t\t\t__skb_queue_tail(\u0026frags_q, skb_frag);\n 149:\t\n 150:\t\t\tdata += frag_len;\n 151:\t\t\ttotal_len -= frag_len;\n 152:\t\n 153:\t\t\tpr_debug(\"frag_len %d, remaining total_len %d\\n\",\n 154:\t\t\t\t frag_len, total_len);\n 155:\t\t}\n 156:\t\n 157:\t\t/* queue all fragments atomically */\n 158:\t\tspin_lock_irqsave(\u0026ndev-\u003etx_q.lock, flags);\n 159:\t\n 160:\t\twhile ((skb_frag = __skb_dequeue(\u0026frags_q)) != NULL)\n 161:\t\t\t__skb_queue_tail(\u0026ndev-\u003etx_q, skb_frag);\n 162:\t\n 163:\t\tspin_unlock_irqrestore(\u0026ndev-\u003etx_q.lock, flags);\n 164:\t\n"
} |
| 39/3 | 2026/09/21 00:43 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 3766 output: 23 thoughts: 272 Thoughts: **Analyzing a Kernel NFC Driver Patch** Okay, let's dive into this commit and figure out what it's addressing. The code's changed within `net/nfc/nci/data.c`. Looking at the "before" snippet, there's a loop that fragments data, and the fragmentation size is determined by `conn_info->max_pkt_payload_len`. Immediately, the red flag goes up: what if that length is zero? The original code would calculate `frag_len` as zero, leading to an infinite loop. I can see that clearly – it's a classic off-by-one or edge-case bug, likely causing a denial-of-service, or potentially a serious memory allocation issue as it tries to allocate zero-length skbs. Also, I need to consider race conditions. What if `conn_info->max_pkt_payload_len` is read concurrently by another thread, and changes *during* the loop? That could create similar problems. The patch's fix makes sense. It introduces a `READ_ONCE()` for a safe read to `max_len` before the loop, and then a quick check for zero before proceeding. This is a solid, clean solution. The early exit with `-EPROTO` is a reasonable error code given this situation. Now, the key is to understand the *why*. Was this a known issue? Was this a race condition discovered in the field? I need to check the commit history and see if there's any context from upstream. Knowing the history behind this patch is essential for understanding its full impact and any potential for side-effects. |
| 40/3 | 2026/09/21 00:43 | tool | grepper |
0mArgs:{
"Expression": "the rx workqueue may update the field concurrently"
}Results: {
"Output": "net/nfc/nci/data.c=97=static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n--\nnet/nfc/nci/data.c-117-\nnet/nfc/nci/data.c:118:\t/* the rx workqueue may update the field concurrently */\nnet/nfc/nci/data.c-119-\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\n"
} |
| 41/3 | 2026/09/21 00:43 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 4544 output: 25 thoughts: 20 Thoughts: Here's my summary, as if I were thinking these thoughts: **Analyzing the Callers of `nci_queue_tx_data_frags`** Okay, time to dig into the `nci_queue_tx_data_frags` function. My initial thought is, let's trace its usage. I'm already envisioning the potential call chains – figuring out *why* this specific function is being invoked is the critical first step. I need to understand the contexts, the data it's operating on, and any dependencies it has. What are the calling contexts here? Is it a high-priority interrupt handler? Or a lower-priority tasklet? Determining this will give me insights into potential performance bottlenecks or concurrency issues. I'll need to look at any parameters passed to the function to see if they're relevant, and how the program handles the return values. I'll quickly look at the surrounding code to determine how data is prepared, transmitted, and cleaned up after. My goal is to quickly build a mental map of this function's role in the system. |
| 42/3 | 2026/09/21 00:44 | tool | grepper |
0mArgs:{
"Expression": "nci_queue_tx_data_frags"
}Results: {
"Output": "net/nfc/nci/data.c=95=EXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);\nnet/nfc/nci/data.c-96-\nnet/nfc/nci/data.c:97:static int nci_queue_tx_data_frags(struct nci_dev *ndev,\nnet/nfc/nci/data.c-98-\t\t\t\t __u8 conn_id,\n--\nnet/nfc/nci/data.c=179=int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\n--\nnet/nfc/nci/data.c-199-\t\t/* fragment packet and queue the fragments */\nnet/nfc/nci/data.c:200:\t\trc = nci_queue_tx_data_frags(ndev, conn_id, skb);\nnet/nfc/nci/data.c-201-\t\tif (rc) {\n"
} |
| 43/3 | 2026/09/21 00:44 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 5090 output: 21 thoughts: 25 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person: **Analyzing `conn_info` and Payload Limits** Okay, so I'm looking at how we're setting up the `conn_info` structure and specifically how `max_pkt_payload_len` is being utilized. My immediate thought is to check how it's initialized - what default value, if any, is being employed, and where that value comes from. Understanding the origin of this limit is critical, as a poor default or incorrect initialization can quickly lead to fragmentation issues, inefficient use of bandwidth, or even security vulnerabilities if we're not careful about how the application reacts to the size. I'll be drilling down to pinpoint exactly *where* `max_pkt_payload_len` influences the application logic. I'll need to trace its use across packet construction, transmission, and reception to see where it impacts buffer allocation or size checks. Are we actively utilizing it to prevent oversized packets, or is it solely used to set up the connection initially? I need to understand its impact at the application layer too, to consider how the value impacts the overall protocol efficiency. I'll be particularly vigilant for cases where this limit might be bypassed accidentally or maliciously, especially in code dealing with externally sourced data. And, finally, I'm thinking about the implications for different transports—TCP, UDP—and whether this limit is handled consistently across protocols. |
| 44/3 | 2026/09/21 00:44 | tool | grepper |
0mArgs:{
"Expression": "max_pkt_payload_len"
}Results: {
"Output": "include/net/nfc/nci_core.h=99=struct nci_conn_info {\n--\ninclude/net/nfc/nci_core.h-108-\t__u8\tconn_id;\ninclude/net/nfc/nci_core.h:109:\t__u8\tmax_pkt_payload_len;\ninclude/net/nfc/nci_core.h-110-\n--\nnet/nfc/nci/data.c=85=int nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id)\n--\nnet/nfc/nci/data.c-92-\nnet/nfc/nci/data.c:93:\treturn conn_info-\u003emax_pkt_payload_len;\nnet/nfc/nci/data.c-94-}\n--\nnet/nfc/nci/data.c=97=static int nci_queue_tx_data_frags(struct nci_dev *ndev,\n--\nnet/nfc/nci/data.c-118-\t/* the rx workqueue may update the field concurrently */\nnet/nfc/nci/data.c:119:\tmax_len = READ_ONCE(conn_info-\u003emax_pkt_payload_len);\nnet/nfc/nci/data.c-120-\n--\nnet/nfc/nci/data.c=179=int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)\n--\nnet/nfc/nci/data.c-192-\t/* check if the packet need to be fragmented */\nnet/nfc/nci/data.c:193:\tif (skb-\u003elen \u003c= conn_info-\u003emax_pkt_payload_len) {\nnet/nfc/nci/data.c-194-\t\t/* no need to fragment packet */\n--\nnet/nfc/nci/hci.c=142=static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,\n--\nnet/nfc/nci/hci.c-155-\ti = 0;\nnet/nfc/nci/hci.c:156:\tskb = nci_skb_alloc(ndev, conn_info-\u003emax_pkt_payload_len +\nnet/nfc/nci/hci.c-157-\t\t\t NCI_DATA_HDR_SIZE, GFP_ATOMIC);\n--\nnet/nfc/nci/hci.c-165-\t\t/* If last packet add NCI_HFP_NO_CHAINING */\nnet/nfc/nci/hci.c:166:\t\tif (i + conn_info-\u003emax_pkt_payload_len -\nnet/nfc/nci/hci.c-167-\t\t (skb-\u003elen + 1) \u003e= data_len) {\n--\nnet/nfc/nci/hci.c-170-\t\t} else {\nnet/nfc/nci/hci.c:171:\t\t\tlen = conn_info-\u003emax_pkt_payload_len - skb-\u003elen - 1;\nnet/nfc/nci/hci.c-172-\t\t}\n--\nnet/nfc/nci/hci.c-186-\t\t\tskb = nci_skb_alloc(ndev,\nnet/nfc/nci/hci.c:187:\t\t\t\t\t conn_info-\u003emax_pkt_payload_len +\nnet/nfc/nci/hci.c-188-\t\t\t\t\t NCI_DATA_HDR_SIZE, GFP_ATOMIC);\n--\nnet/nfc/nci/ntf.c=709=static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/ntf.c-858-\nnet/nfc/nci/ntf.c:859:\t\tconn_info-\u003emax_pkt_payload_len = ntf.max_data_pkt_payload_size;\nnet/nfc/nci/ntf.c-860-\t\tconn_info-\u003einitial_num_credits = ntf.initial_num_credits;\n--\nnet/nfc/nci/rsp.c=305=static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/rsp.c-347-\t\tconn_info-\u003econn_id = rsp-\u003econn_id;\nnet/nfc/nci/rsp.c:348:\t\tconn_info-\u003emax_pkt_payload_len = rsp-\u003emax_ctrl_pkt_payload_len;\nnet/nfc/nci/rsp.c-349-\t\tatomic_set(\u0026conn_info-\u003ecredits_cnt, rsp-\u003ecredits_cnt);\n"
} |
| 45/3 | 2026/09/21 00:44 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 6679 output: 19 thoughts: 506 Thoughts: **Analyzing a Potential Vulnerability in NCI TX Data Fragmentation** Okay, let's break this down. My initial concern is with the `conn_info->max_pkt_payload_len` value. It appears this value is populated from NCI control packets, specifically responses like `nci_rf_intf_activated_ntf_packet` and `nci_core_conn_create_rsp_packet`. If a rogue or malfunctioning device were to set this value to zero, or if it were changed concurrently during TX data fragmentation, we'd have a potential infinite loop in `nci_queue_tx_data_frags`, which is never good. The proposed patch addresses this by adding a check: a `READ_ONCE` call to fetch `max_len` from `conn_info->max_pkt_payload_len`. If `max_len` is zero, it returns an error. This is followed by using `max_len` within a `min_t` call in the fragmentation loop. Seems solid as a protection to me. Now, the question is whether this patch introduces any new risks, specifically uninitialized memory issues. We need to check against the four criteria for setting `NeedsKMSAN=true`. 1. Kernel structures sent to userspace? No, this code is purely about preparing `sk_buffs` (presumably, network buffers) for transmission. No direct interaction with userspace via copy operations. So, that's not it. 2. Conditional logic based on uninitialized variables? The code fetches `max_len` *before* the conditional check with `READ_ONCE(conn_info->max_pkt_payload_len)`. The thing I need to confirm now is that `conn_info` is initialized, which is allocated with `devm_kzalloc`. Therefore, it *should* be zeroed on allocation. So this isn't an issue. 3. Allocation or initialization of complex data structures with uninitialized fields? No, it's just fetching the `max_pkt_payload_len` from an existing structure, so no new allocations are introduced. 4. Bounds checks or logic that could expose uninitialized bytes? The patch checks for and immediately exits if the value is zero. The `min_t` call prevents writing beyond the bounds of the valid buffer. Based on this assessment, I don't see any immediate reason to suspect uninitialized memory risks. The patch looks like a good, solid fix for a potential integer overflow vulnerability. Therefore, I don't think `NeedsKMSAN=true` is warranted here. |
| 46/3 | 2026/09/21 00:44 | tool | grepper |
0mArgs:{
"Expression": "conn_info.*alloc"
}Results: {
"Output": "drivers/net/wireless/intel/iwlwifi/mvm/ops.c=1090=static void iwl_mvm_me_conn_status(void *priv, const struct iwl_mei_conn_info *conn_info)\n--\ndrivers/net/wireless/intel/iwlwifi/mvm/ops.c-1100-\ndrivers/net/wireless/intel/iwlwifi/mvm/ops.c:1101:\tcurr_conn_info = kzalloc_obj(*curr_conn_info);\ndrivers/net/wireless/intel/iwlwifi/mvm/ops.c-1102-\tif (!curr_conn_info)\n--\ndrivers/scsi/qedi/qedi_iscsi.c=432=static int qedi_iscsi_update_conn(struct qedi_ctx *qedi,\n--\ndrivers/scsi/qedi/qedi_iscsi.c-442-\ndrivers/scsi/qedi/qedi_iscsi.c:443:\tconn_info = kzalloc_obj(*conn_info);\ndrivers/scsi/qedi/qedi_iscsi.c-444-\tif (!conn_info) {\n--\ndrivers/scsi/qedi/qedi_iscsi.c=501=static int qedi_iscsi_offload_conn(struct qedi_endpoint *qedi_ep)\n--\ndrivers/scsi/qedi/qedi_iscsi.c-507-\ndrivers/scsi/qedi/qedi_iscsi.c:508:\tconn_info = kzalloc_obj(*conn_info);\ndrivers/scsi/qedi/qedi_iscsi.c-509-\tif (!conn_info) {\n--\nnet/nfc/nci/core.c=1318=void nci_unregister_device(struct nci_dev *ndev)\n--\nnet/nfc/nci/core.c-1337-\t\tlist_del(\u0026conn_info-\u003elist);\nnet/nfc/nci/core.c:1338:\t\t/* conn_info is allocated with devm_kzalloc */\nnet/nfc/nci/core.c-1339-\t}\n--\nnet/nfc/nci/rsp.c=220=static void nci_rf_disc_rsp_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/rsp.c-232-\t\tif (!conn_info) {\nnet/nfc/nci/rsp.c:233:\t\t\tconn_info = devm_kzalloc(\u0026ndev-\u003enfc_dev-\u003edev,\nnet/nfc/nci/rsp.c-234-\t\t\t\t\t\t sizeof(struct nci_conn_info),\n--\nnet/nfc/nci/rsp.c=305=static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,\n--\nnet/nfc/nci/rsp.c-316-\nnet/nfc/nci/rsp.c:317:\t\tconn_info = devm_kzalloc(\u0026ndev-\u003enfc_dev-\u003edev,\nnet/nfc/nci/rsp.c-318-\t\t\t\t\t sizeof(*conn_info), GFP_KERNEL);\n--\nnet/nfc/nci/rsp.c-323-\nnet/nfc/nci/rsp.c:324:\t\tconn_info-\u003edest_params = devm_kzalloc(\u0026ndev-\u003enfc_dev-\u003edev,\nnet/nfc/nci/rsp.c-325-\t\t\t\t\t\tsizeof(struct dest_spec_params),\n"
} |
| 47/3 | 2026/09/21 00:44 | llm | kmsan-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 8681 output: 191 thoughts: 664 Thoughts: **KMSAN Check: No Uninitialized Memory Risk** Okay, let's break this down. From what I see, we're dealing with a patch that fixes a potential infinite loop or soft lockup scenario. The core of the issue seems to stem from `conn_info->max_pkt_payload_len` potentially being zero, which leads to a loop where `frag_len` ends up also zero, causing the loop to never terminate. First, `conn_info` is safely initialized with `devm_kzalloc`, which is good practice. `max_len` is then initialized using `READ_ONCE(conn_info->max_pkt_payload_len)`. The key part is that, if `max_len` is zero, the code now returns `-EPROTO`. This avoids the infinite loop. If `max_len` is greater than 0, it properly fragments the packet, and importantly, it handles the `conn_info->max_pkt_payload_len` changing midway without concurrency issues. My immediate assessment is that this patch doesn't introduce any uninitialized memory reads. `frag_len` is always positive (or zero, in which case we exit). `skb_put_data` copies `frag_len` bytes from `data` into the newly allocated `skb_frag`. The allocation size for `skb_frag` depends on `frag_len`, and the data is always written. We are not reading any uninitialized memory. To be absolutely thorough, let's double-check: * `max_len` is unconditionally initialized. * No other variables are uninitialized. Returning `-EPROTO` handles the zero case safely. * `skb_frag` itself doesn't contain uninitialized data: The allocation size is based on the result of a conditional expression. * No data is copied to userspace, so it's not a security issue that is KMSAN-related. Therefore, since there are no uninitialized memory risks here, `NeedsKMSAN` should be `false`. Ready to call `set-results`. |
| 48/3 | 2026/09/21 00:44 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch addresses a concurrency and infinite loop issue in `nci_queue_tx_data_frags` by capturing `conn_info-\u003emax_pkt_payload_len` with `READ_ONCE()` into a local variable `max_len` and validating that `max_len` is non-zero before chunking outgoing packets.\n\nThis modification does not touch any uninitialized stack or heap allocations, does not copy kernel memory to user space, and does not alter buffer bounds in a manner that could expose uninitialized memory. The underlying issue is an infinite loop / hung task and a data race, which fall under standard kernel testing / KCSAN / lockup detectors, rather than uninitialized memory access detectable by KMSAN. Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch addresses a concurrency and infinite loop issue in `nci_queue_tx_data_frags` by capturing `conn_info-\u003emax_pkt_payload_len` with `READ_ONCE()` into a local variable `max_len` and validating that `max_len` is non-zero before chunking outgoing packets.\n\nThis modification does not touch any uninitialized stack or heap allocations, does not copy kernel memory to user space, and does not alter buffer bounds in a manner that could expose uninitialized memory. The underlying issue is an infinite loop / hung task and a data race, which fall under standard kernel testing / KCSAN / lockup detectors, rather than uninitialized memory access detectable by KMSAN. Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|