kernel/git/next/linux-next.git/net/nfc, branch master

Merge branch 'for-next' of https://codeberg.org/linux-nfc/linux.git

2026-07-15T13:23:37+00:00

# Conflicts: # net/nfc/nci/rsp.c

Merge branch 'for-linus' of https://codeberg.org/linux-nfc/linux.git

2026-07-15T11:27:00+00:00

nfc: nci: fix out-of-bounds write in nci_target_auto_activated()

2026-06-27T18:33:52+00:00

nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target(). Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260622145243.3167276-1-sam@bynar.io Signed-off-by: David Heidelberg

nfc: nci: fix uninit-value in nci_core_init_rsp_packet()

2026-06-27T18:06:24+00:00

The CORE_INIT_RSP handlers walk the response using length fields taken from the packet itself, without checking they stay within skb->len: - v1 computes rsp_2 = skb->data + 6 + rsp_1->num_supported_rf_interfaces; from the on-wire (unclamped) interface count and then dereferences rsp_2, and memcpy()s the advertised interfaces - both can run past the received data; - v2 walks supported_rf_interfaces[], advancing the cursor by an in-packet rf_extension_cnt with no bound. A short CORE_INIT_RSP therefore makes the parser read past the packet (into the uninitialised tail of the RX skb); the values are stored into struct nci_dev and consumed while bringing the device up: BUG: KMSAN: uninit-value in nci_dev_up+0x10f3/0x1720 nci_dev_up+0x10f3/0x1720 nfc_dev_up+0x187/0x380 nfc_genl_dev_up+0xdc/0x1a0 genl_rcv_msg+0x5d4/0x9e0 netlink_rcv_skb+0x28f/0x530 Uninit was stored to memory at: nci_rsp_packet+0x68f/0x2310 nci_rx_work+0x25f/0x5d0 Uninit was created at: __alloc_skb+0x540/0xd40 virtual_ncidev_write+0x65/0x210 Validate the response length before parsing or storing the variable-length parts, rejecting truncated responses with NCI_STATUS_SYNTAX_ERROR. In v1 the check is done before num_supported_rf_interfaces is stored into ndev, so a truncated response cannot leave ndev->num_supported_rf_interfaces holding the unclamped on-wire count, which nci_init_complete_req() would otherwise use as a bound for the fixed-size supported_rf_interfaces[] array. Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence") Cc: stable@vger.kernel.org Tested-by: syzbot@syzkaller.appspotmail.com Assisted-by: Bynario AI Signed-off-by: Samuel Page Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260624224455.999374-1-sam@bynar.io Signed-off-by: David Heidelberg

nfc: nci: add data_len bound checks to activation parameter extractors

2026-06-24T16:51:55+00:00

nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 ("net: nfc: nci: Fix parameter validation for packet data"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801. Fixes: e8c0dacd9836 ("NFC: Update names and structs to NCI spec 1.0 d18") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260612-b4-disp-6d52d8b0-v3-1-e26221f8826d@proton.me Signed-off-by: David Heidelberg

nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers

2026-06-24T16:15:58+00:00

nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access. Fixes: 3df40eb3a2ea ("nfc: constify several pointers to u8, char and sk_buff") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260622131802.239035-1-meatuni001@gmail.com Signed-off-by: David Heidelberg

nfc: llcp: bound SNL TLV parsing to the skb and add length checks

2026-06-21T16:32:10+00:00

nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made "service_name_len = length - 1" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 19cfe5843e86 ("NFC: Initial SNL support") Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260609202543.42282-1-doruk@0sec.ai Signed-off-by: David Heidelberg

nfc: llcp: bound SNL TLV parsing to the skb and add length checks

2026-06-21T16:31:36+00:00

nfc: digital: clamp SENSF_RES length to the destination buffer

2026-06-18T13:10:38+00:00

digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 8c0695e4998d ("NFC Digital: Add NFC-F technology support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260603141355.68156-1-doruk@0sec.ai Signed-off-by: David Heidelberg

nfc: nci: fix double completion race in nci_data_exchange_complete

2026-06-18T13:10:37+00:00

nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 ("nfc: nci: fix circular locking dependency in nci_close_device") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback. Fixes: 4527025d440c ("nfc: nci: fix circular locking dependency in nci_close_device") Signed-off-by: Zhenghang Xiao Link: https://patch.msgid.link/20260526103121.47957-1-kipreyyy@gmail.com Signed-off-by: David Heidelberg