From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-99109][IMPORTANT] smb: client: reject SetEA requests that do not fit the request buffer Date: Thu, 29 Oct 2026 00:31:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-99109 X-AL-KERNEL-Priority: IMPORTANT X-AL-KERNEL-Severity: IMPORTANT X-AL-KERNEL-Base-Severity: IMPORTANT X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: 9efbd764ab80fa86d2258550877a74d78a25e855 List-Id: CVE: CVE-2026-99109 Priority: IMPORTANT AL-KERNEL base severity: IMPORTANT KPANIC flag: NO Patch: smb: client: reject SetEA requests that do not fit the request buffer Commit: 9efbd764ab80fa86d2258550877a74d78a25e855 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9efbd764ab80fa86d2258550877a74d78a25e855 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-99109 Analysis date: Thu, 29 Oct 2026 00:31:44 -0400 ActionableScore: 5 ActionableScore lower bound: unknown Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review Manual review required: YES Summary: An unprivileged user with access to a writable SMB1 mount can supply an oversized EA that causes a controlled 141-byte heap overwrite while the client constructs a SetEA request. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-99109 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-99109 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-99109 IMPORTANT https://www.kernelcve.org/list/?q=CVE-2026-99109 CHECK WITH IMPACT FROM ORIG NN IMPORTANT | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=2 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:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-787;CWE-190;*CWE-20;BEST CVSS score: '7.8';DESCR 'CIFSSMBSetEA copied an attacker controlled extended attribute value before verifying that the complete SMB1 SetEA request fit in the allocated cifs_request buffer. A demonstrated setxattr(2) call writes 141 bytes beyond the slab object, providing a controlled heap out of bounds write that can crash the kernel and may permit local privilege escalation if adjacent kernel objects can be shaped. For the CVSS the PR:L value is selected because an unprivileged local process is required to invoke setxattr on a writable object within an SMB1 mount. The issue is not directly network reachable because the vulnerable copy is performed by the local SMB client while assembling an outgoing request. Confidentiality and integrity are rated High because controlled kernel heap corruption is a concrete primitive, although exploitation beyond denial of service depends on slab layout and a useful adjacent object. Automated impact decision path. The original SimpleNet classifier selected IMPORTANT. The primary LLM estimated paranoid CVSS 7.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. Recorded rule transitions were final reconciliation stage IMPORTANT to IMPORTANT because KP specialist did not establish a qualifying panic. 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 and KPANIC_UNSUPPORTED_REMOVED. The independent weaker Aegis shadow evaluated CVSS 3.3 and ActionableScore 2 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 WRITE KASAN OOB DISK LEAK IMPROVEONLY SERVERTOCLIENT LINUS TEMP_KPANIC_MERGE_IMPORTANT_WINS KPANIC_UNSUPPORTED_REMOVED - - checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 PrimitiveClass=CLASS_A RealUAF=NO HostAdminRequired=NO NamespaceScopedPrivilege=UNKNOWN ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO RequiresHostUID0=NO AuthorizationDecisionBypass=NO ProtectedResourceImpact=NONE B4PendingReview=NO B4PendingConfirmed=NO 1. ActionableScore * Raw base score: 5. * Conservative score: 5; no floor or cap applied. * Raw paranoid score: 5. * Paranoid score: 5; no additional effect is sufficiently proven. * Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**:: 2. Signal breakdown * +2 — Strong corruption primitive: attacker-supplied EA bytes are copied beyond the allocated `cifs_request`; the demonstrated case writes 141 bytes past the slab object. * +1 — Local unprivileged trigger: `setxattr(2)` by an unprivileged user on a writable SMB1 mount reaches the copy. * +1 — High-control local API: the caller materially controls the EA value, length, and therefore the overflowing payload. * +1 — Plausible kernel crash/strong DoS: KASAN confirms the slab OOB write; production corruption can plausibly fault, though panic is not guaranteed. * No separate integrity/confidentiality, LPE, controlled-adjacent-object, arbitrary-target, or practical exploit-chain points: none is demonstrated. * No extra availability point: it would duplicate the same possible crash. * NEW52 B5-R does not apply: this is a single request-sizing failure, not an index accumulated across retries. * B4 authorization profiles do not apply; no DENY-to-ALLOW decision is involved. 3. Reachability analysis The grounded attacker is a non-root local user with write and xattr permission on an object in an existing SMB1 mount. An SMB1 mount and writable object are prerequisites, but the triggering `setxattr()` itself does not require host-administrator powers or UID 0. Namespace capability scope and who provisioned the mount are not established. No race, retry manipulation, special hardware, or direct network trigger is required. 4. Primitive and severity reading This is a controlled heap/slab OOB write, not a UAF or fixed harmless overwrite. The pre-copy size check was missing: a 16,384-byte attacker value begins 345 bytes into a 16,588-byte allocation and overruns it by 141 bytes. This is CLASS_A because both the existence and contents of the overwrite are attacker-influenced. Adjacent-object selection, useful victim consumption, arbitrary write, disclosure, and LPE remain unproven. Important review is warranted despite the score of 5; auto-downgrade would discard a concrete controlled kernel heap-corruption primitive. 5. One-sentence report phrase An unprivileged user with access to a writable SMB1 mount can supply an oversized EA that causes a controlled 141-byte heap overwrite while the client constructs a SetEA request. 6. Manual review advice MANUAL CHECK REQUIRED Concrete attacker-controlled slab corruption requires exploitability and allocator-adjacency review. 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: smb: client: reject SetEA requests that do not fit the request buffer Commit: 9efbd764ab80fa86d2258550877a74d78a25e855 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9efbd764ab80fa86d2258550877a74d78a25e855 Commit description: CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE) CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so that total_len is assigned before it is reported. Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: Yunpeng Tian Reported-by: Mingda Zhang Reported-by: Gongming Wang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman Changed files: fs/smb/client/cifssmb.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=9efbd764ab80fa86d2258550877a74d78a25e855 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-99109 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-99109 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: Not available The Best / paranoid CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H The Best / paranoid CVSS score: 7.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: unknown 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 alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).