* [CVE-2026-98483][IMPORTANT] nfc: fix use-after-free in nfc_get_local_general_bytes
@ 2026-10-19 4:46 21% AL-KERNEL
0 siblings, 0 replies; 1+ results
From: AL-KERNEL @ 2026-10-19 4:46 UTC (permalink / raw)
To: kernel-cve
CVE: CVE-2026-98483
Priority: IMPORTANT
AL-KERNEL base severity: IMPORTANT
KPANIC flag: NO
Patch: nfc: fix use-after-free in nfc_get_local_general_bytes
Commit: 25bfa673adc70189c0bc872940421ae59f789cf6
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=25bfa673adc70189c0bc872940421ae59f789cf6
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98483
Analysis date: Mon, 19 Oct 2026 00:46:10 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES
Summary:
A freed NFC LLCP general-bytes buffer can remain in use across multiple protocol callers, creating a kernel UAF read with plausible crash and adjacent stale-heap disclosure consequences.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-98483 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98483
The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.
The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.
Published priority for this report: IMPORTANT
Manual review required: YES
A detailed explanation of the methodology and priority rules is included
at the end of this message.
======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================
CVE-2026-98483 IMPORTANT https://www.kernelcve.org/list/?q=CVE-2026-98483 CHECK WITH IMPACT FROM ORIG NN IMPORTANT | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=4 LEGACY=IMPORTANT RESULT=DIFF INDEPENDENT_LEGACY=IMPORTANT INDEPENDENT_RESULT=DIFF TEMP_KPANIC_MERGE=IMPORTANT_WINS_DISAGREEMENT PRE_MERGE_LEGACY=IMPORTANT (final Legacy and Aegis differ; FINAL: IMPORTANT, Aegis: MODERATE_KPANIC) Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H';*CWE-416;*CWE-672;CWE-362;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H';BEST CVSS score: '6.8';DESCR 'nfc_llcp_general_bytes can return local gb after nfc_llcp_local_put has released the final reference to the containing nfc_llcp_local object. Callers may then read freed kernel memory while preparing NFC DEP or LLCP data, which can cause a kernel crash or expose stale heap contents through an NFC exchange. The demonstrated primitive is a use-after-free read and no direct write primitive is visible in the affected path. For the CVSS the PR:N value is used for the paranoid score because a nearby NFC peer may not need an account on the target when it can initiate the relevant protocol exchange. Reliable triggering still appears to require a narrow lifetime window or concurrent local object teardown, so AC:H is appropriate. The issue is adjacent rather than generally Internet reachable because the attacker must normally be within NFC communication range and the target must have an affected NFC device and protocol path enabled. Impact is at least denial of service through a kernel crash and may include confidentiality loss if reused kernel heap data is copied into transmitted general bytes. Privilege escalation is not established by the visible read primitive and requires manual source and runtime validation. Automated impact decision path. The original SimpleNet classifier selected IMPORTANT. The primary LLM estimated paranoid CVSS 6.8 and the production ActionableScore returned 5 with recommendation Actionable Moderate / Strong Important candidate requiring manual review. The production rules then evaluated CVSS thresholds and ActionableScore thresholds. No severity changing production threshold or specialist override was recorded. The legacy KP specialist has no review artifact for this run. The legacy FD or DH downgrade specialist produced a review artifact and its decision was processed by the applicable downgrade and preservation rules. Exact triggered rule markers were TEMP_KPANIC_MERGE_IMPORTANT_WINS. The independent weaker Aegis shadow evaluated CVSS 3.7 and ActionableScore 4 with primitive class CLASS_B and manual review REQUIRED. Its independently reconciled impact was MODERATE_KPANIC. Cross model aggregation changed the production result under an enabled evidence gated merge rule. The final reported impact is IMPORTANT.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) MAYBE LEAK UAF SKB IMPROVEONLY LINUS TEMP_KPANIC_MERGE_IMPORTANT_WINS - - checked
======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================
ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=UNKNOWN
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO
RequiresHostUID0=UNKNOWN
AuthorizationDecisionBypass=NO
ProtectedResourceImpact=NONE
B4PendingReview=NO
B4PendingConfirmed=NO
1. ActionableScore
* Raw conservative score: 3.
* Conservative score: 4. REAL UAF FLOOR 4 changes 3 to 4 because a returned pointer is consumed after the final reference may free its containing object, and host-admin privilege is not established.
* Raw paranoid score: 5.
* Paranoid score: 5. No floor or cap changes it.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::
2. Signal breakdown
Conservative signals:
* +2 Real UAF. `nfc_llcp_local_put(local)` can free `local`, but the old implementation then returns `local->gb`.
* +1 Strong DoS concern. Multiple callers consume the dangling buffer and an invalid post-free read can produce a kernel fault.
* No negative privilege penalty. The complete trigger privilege is unresolved, so host-admin access cannot be assumed.
* No race penalty. Concurrent teardown may be relevant, but the supplied evidence does not establish a narrow or uncontrollable race.
Paranoid additions:
* +1 Firmware-mediated adjacent influence. `digital_tg_send_atr_res()` places the helper in an NFC protocol response path, making influence by a nearby NFC peer technically credible, although the complete peer-controlled trigger is unresolved.
* +1 Confidentiality plausible. A caller can copy the stale general-bytes region into NFC protocol output after its containing slab object has been freed and potentially reused.
Signals not awarded:
* Controlled reclaim, attacker-shaped replacement contents, arbitrary write, callback control, refcount takeover, and LPE are not demonstrated.
* Structured stale-object leverage is not awarded. The stale operation reads the embedded `gb` byte array, but attacker control over reclaimed object state is not established.
* Repeatable lifetime manipulation is not awarded because one attacker is not shown to control both LLCP teardown and the later stale read.
* Direct network reachability +2 is not awarded. NFC hardware and protocol state mediate the path, and ordinary Internet packets cannot reach it.
* No second put, free, or refcount mutation occurs through the dangling pointer. The concrete repeated-release signal and FLOOR 5 based on repeated release do not apply.
* No extra Availability point is awarded for the same possible kernel fault.
* B5-R, B3-PENDING, V32, V33, and V34 do not apply. There is no retry-accumulated OOB write, shared-backing write, checksum metadata corruption, or active structured-state write.
* Authorization bypass signals do not apply.
3. Reachability analysis
The affected system must have a supported NFC device and execute an NFC-DEP or LLCP path that requests local general bytes. Visible callers include polling, link setup, and target response paths across several NFC drivers.
A nearby peer may influence the target response path, particularly through an incoming ATR exchange, but the supplied code does not prove that the peer can independently cause the LLCP local object to lose its final reference at the required time. The complete adjacent trigger therefore remains unresolved.
Local NFC control may require netlink permissions, device access, or prior NFC configuration. The supplied context does not identify all applicable capability checks or show that the complete operation works in an attacker-created namespace. Consequently, host-admin and namespace-scoped privilege remain UNKNOWN.
NFC hardware is required, but no rare-hardware penalty is applied merely because the bug is in a hardware-backed subsystem. Concurrent removal or teardown may create the final-reference condition, but repeatability and attacker control over that transition are not established.
4. Primitive and severity interpretation
The exact primitive is a post-lifetime read through a pointer to `local->gb`. The pointer refers to an embedded byte array inside an active `nfc_llcp_local` object. After `nfc_llcp_local_put()` drops the final reference, the entire containing object can be freed before callers consume the returned pointer.
This is a real CLASS_B UAF rather than a hypothetical lifetime concern. It is broader than an immediate destructor-only fault because the dangling pointer escapes the helper and is consumed by multiple driver and protocol call sites. Some consumers use the bytes while constructing NFC protocol data, creating an unresolved disclosure path.
There is no concrete repeated release or refcount mutation through the dangling pointer. The stale use is a read, not a write. Controlled slab reuse and privilege escalation are speculative and are not scored.
The demonstrated consequence is unsafe access to freed kernel storage. Kernel crash is plausible. Disclosure of reused heap bytes through NFC output is technically defensible but requires validation of timing, allocator reuse, and peer-visible transmission.
ImportantCandidate is YES because a real escaping UAF reaches protocol consumers and may disclose stale kernel heap contents. Manual validation is needed to distinguish a constrained crash from a peer-observable disclosure primitive. AutoDowngradeAllowed is NO because automatic closure would discard this unresolved post-free data-consumption path.
Likely operational severity is Actionable Moderate, with an Important candidate retained for manual analysis rather than a proven Important or LPE classification.
5. One-sentence report phrase
A freed NFC LLCP general-bytes buffer can remain in use across multiple protocol callers, creating a kernel UAF read with plausible crash and adjacent stale-heap disclosure consequences.
6. Manual review recommendation
MANUAL CHECK REQUIRED
Confirm whether an adjacent NFC peer can reach the vulnerable response path while the LLCP local object loses its final reference, and determine whether reclaimed slab contents can be copied into peer-visible protocol output.
7. Call-site confidence
Call-site confidence: medium
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: nfc: fix use-after-free in nfc_get_local_general_bytes
Commit: 25bfa673adc70189c0bc872940421ae59f789cf6
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=25bfa673adc70189c0bc872940421ae59f789cf6
Commit description:
Commit 6709d4b ("net: nfc: Fix use-after-free caused by
nfc_llcp_find_local") attempted to fix a use-after-free (UAF) issue by
invoking nfc_llcp_local_put(local) after accessing local->gb. However,
if the reference count drops to zero, local is freed immediately,
leading to a use-after-free when callers access the returned pointer.
Alternative approaches using dynamic allocation (e.g. kmemdup) introduced
memory leaks because callers consistently treat the returned pointer as
borrowed memory.
Fix this properly by refactoring nfc_llcp_general_bytes() and
nfc_get_local_general_bytes() to accept a caller-provided output buffer
(out_gb) and its maximum length (gb_max_len). The general bytes are
safely copied into out_gb before calling nfc_llcp_local_put(local),
ensuring safe lifetime management without ownership transfer complications.
Update all callers across drivers (microread, pn533, pn544, st21nfca,
digital_dep, and nci) to provide their own destination buffers and pass
them to nfc_get_local_general_bytes().
Fixes: 6709d4b ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local")
Cc: [email protected]
Reported-by: Vega <[email protected]>
Assisted-by: LLM
Signed-off-by: Luxiao Xu <[email protected]>
Signed-off-by: Ren Wei <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://patch.msgid.link/3cbaac3bee23f8ff3a3284ed32d347696eb1d208.1788841683.git.rakukuip@gmail.com
Signed-off-by: David Heidelberg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
drivers/nfc/microread/microread.c
drivers/nfc/pn533/pn533.c
drivers/nfc/pn533/pn533.h
net/nfc/nfc.h
drivers/nfc/pn544/pn544.c
drivers/nfc/st21nfca/core.c
include/net/nfc/hci.h
include/net/nfc/nfc.h
net/nfc/core.c
net/nfc/digital_dep.c
net/nfc/llcp_core.c
Diff excerpt:
Not included in this email. See the upstream URL for the full patch.
Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=25bfa673adc70189c0bc872940421ae59f789cf6
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-98483 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98483
The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.
The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.
This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.
The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.
Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:
Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H
The Best / paranoid CVSS vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
The Best / paranoid CVSS score: 6.8
The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.
CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.
A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.
Conservative ActionableScore: 4
Paranoid ActionableScore: 5
The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.
For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:
ActionableScore below 5 -> MODERATE REGULAR
ActionableScore 5 or more -> MODERATE 7.0
The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.
There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).
KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.
AL-KERNEL base severity for this report: IMPORTANT
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): IMPORTANT
These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).
Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
^ permalink raw reply [relevance 21%]
Results 1-1 of 1 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2026-10-19 4:46 21% [CVE-2026-98483][IMPORTANT] nfc: fix use-after-free in nfc_get_local_general_bytes AL-KERNEL
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox