Linux: Stack-based Buffer Overflow
CVE-2026-31630 is a high-severity stack-based buffer overflow vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 386c86412608d3449006a318a662cbcd6ca1f668, 235b2115de892eab2e107a42efa7a4347baaa80b, 625af53a1564e31bb2df9adc3739df46137f46c1 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.18% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 386c86412608d3449006a318a662cbcd6ca1f668 or 235b2115de892eab2e107a42efa7a4347baaa80b or 625af53a1564e31bb2df9adc3739df46137f46c1 or 808a34cdbe8ce336c202d8ea6d5e48496764dc37, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.18.23 or 6.19.13, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, 386c86412608d3449006a318a662cbcd6ca1f668; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, 235b2115de892eab2e107a42efa7a4347baaa80b; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, 625af53a1564e31bb2df9adc3739df46137f46c1; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, 808a34cdbe8ce336c202d8ea6d5e48496764dc37; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, a6042b8066b24dbcc7945616a157d4d43e463668; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, db297c78ce537c9ac96f0eda9b25ad72c8caefa9; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, 10ebed83f9f6414af4e85bc85ffaeda7effdd874; 75b54cb57ca34cbe7a87c6ac757c55360a624590 up to, but not including, a44ce6aa2efb61fe44f2cfab72bb01544bbca272; and 1 more ranges | 386c86412608d3449006a318a662cbcd6ca1f668, 235b2115de892eab2e107a42efa7a4347baaa80b, 625af53a1564e31bb2df9adc3739df46137f46c1, 808a34cdbe8ce336c202d8ea6d5e48496764dc37, a6042b8066b24dbcc7945616a157d4d43e463668, db297c78ce537c9ac96f0eda9b25ad72c8caefa9 |
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem | all versions | Not stated |
| Linux | Linux Kernel | 4.9.1 up to, but not including, 6.18.23; 6.19 up to, but not including, 6.19.13; 4.9; 7.0 | 6.18.23, 6.19.13 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.
Official description
In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Stack-based Buffer Overflow
The product writes past the end of a buffer that was allocated on the stack.
How developers prevent this class of flaw
- Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND discusses canary-based detection in detail.
- Use an abstraction library to abstract away risky APIs. Not a complete solution.
- Implement and perform bounds checking on input.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
- git.kernel.org/stable/c/235b2115de892eab2e107a42efa7a4347baaa80b
- git.kernel.org/stable/c/386c86412608d3449006a318a662cbcd6ca1f668
- git.kernel.org/stable/c/625af53a1564e31bb2df9adc3739df46137f46c1
- git.kernel.org/stable/c/808a34cdbe8ce336c202d8ea6d5e48496764dc37
- git.kernel.org/stable/c/a6042b8066b24dbcc7945616a157d4d43e463668
- cert-portal.siemens.com/productcert/html/ssa-784472.html
Recent Stack-based Buffer Overflow vulnerabilities
- 8.8 High severity
- 7.5 High severity
- 9.8 Critical severity
- 9.9 Critical severity
- 8.8 High severity
- 8.6 High severity
Spotted an error? Tell us.