CVE-2025-38463 (GCVE-0-2025-38463)
Vulnerability from cvelistv5
Published
2025-07-25 15:27
Modified
2025-07-28 04:23
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
tcp: Correct signedness in skb remaining space calculation
Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow.
When we send data, if an skb exists at the tail of the write queue, the
kernel will attempt to append the new data to that skb. However, the code
that checks for available space in the skb is flawed:
'''
copy = size_goal - skb->len
'''
The types of the variables involved are:
'''
copy: ssize_t (s64 on 64-bit systems)
size_goal: int
skb->len: unsigned int
'''
Due to C's type promotion rules, the signed size_goal is converted to an
unsigned int to match skb->len before the subtraction. The result is an
unsigned int.
When this unsigned int result is then assigned to the s64 copy variable,
it is zero-extended, preserving its non-negative value. Consequently, copy
is always >= 0.
Assume we are sending 2GB of data and size_goal has been adjusted to a
value smaller than skb->len. The subtraction will result in copy holding a
very large positive integer. In the subsequent logic, this large value is
used to update sk->sk_forward_alloc, which can easily cause it to overflow.
The syzkaller reproducer uses TCP_REPAIR to reliably create this
condition. However, this can also occur in real-world scenarios. The
tcp_bound_to_half_wnd() function can also reduce size_goal to a small
value. This would cause the subsequent tcp_wmem_schedule() to set
sk->sk_forward_alloc to a value close to INT_MAX. Further memory
allocation requests would then cause sk_forward_alloc to wrap around and
become negative.
[1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "81373cd1d72d87c7d844d4454a526b8f53e72d00",
"status": "affected",
"version": "270a1c3de47e49dd2fc18f48e46b101e48050e78",
"versionType": "git"
},
{
"lessThan": "62e6160cfb5514787bda833d466509edc38fde23",
"status": "affected",
"version": "270a1c3de47e49dd2fc18f48e46b101e48050e78",
"versionType": "git"
},
{
"lessThan": "9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7",
"status": "affected",
"version": "270a1c3de47e49dd2fc18f48e46b101e48050e78",
"versionType": "git"
},
{
"lessThan": "d3a5f2871adc0c61c61869f37f3e697d97f03d8c",
"status": "affected",
"version": "270a1c3de47e49dd2fc18f48e46b101e48050e78",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.5"
},
{
"lessThan": "6.5",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.99",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.99",
"versionStartIncluding": "6.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.39",
"versionStartIncluding": "6.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.7",
"versionStartIncluding": "6.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16",
"versionStartIncluding": "6.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Correct signedness in skb remaining space calculation\n\nSyzkaller reported a bug [1] where sk-\u003esk_forward_alloc can overflow.\n\nWhen we send data, if an skb exists at the tail of the write queue, the\nkernel will attempt to append the new data to that skb. However, the code\nthat checks for available space in the skb is flawed:\n\u0027\u0027\u0027\ncopy = size_goal - skb-\u003elen\n\u0027\u0027\u0027\n\nThe types of the variables involved are:\n\u0027\u0027\u0027\ncopy: ssize_t (s64 on 64-bit systems)\nsize_goal: int\nskb-\u003elen: unsigned int\n\u0027\u0027\u0027\n\nDue to C\u0027s type promotion rules, the signed size_goal is converted to an\nunsigned int to match skb-\u003elen before the subtraction. The result is an\nunsigned int.\n\nWhen this unsigned int result is then assigned to the s64 copy variable,\nit is zero-extended, preserving its non-negative value. Consequently, copy\nis always \u003e= 0.\n\nAssume we are sending 2GB of data and size_goal has been adjusted to a\nvalue smaller than skb-\u003elen. The subtraction will result in copy holding a\nvery large positive integer. In the subsequent logic, this large value is\nused to update sk-\u003esk_forward_alloc, which can easily cause it to overflow.\n\nThe syzkaller reproducer uses TCP_REPAIR to reliably create this\ncondition. However, this can also occur in real-world scenarios. The\ntcp_bound_to_half_wnd() function can also reduce size_goal to a small\nvalue. This would cause the subsequent tcp_wmem_schedule() to set\nsk-\u003esk_forward_alloc to a value close to INT_MAX. Further memory\nallocation requests would then cause sk_forward_alloc to wrap around and\nbecome negative.\n\n[1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47"
}
],
"providerMetadata": {
"dateUpdated": "2025-07-28T04:23:11.023Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/81373cd1d72d87c7d844d4454a526b8f53e72d00"
},
{
"url": "https://git.kernel.org/stable/c/62e6160cfb5514787bda833d466509edc38fde23"
},
{
"url": "https://git.kernel.org/stable/c/9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7"
},
{
"url": "https://git.kernel.org/stable/c/d3a5f2871adc0c61c61869f37f3e697d97f03d8c"
}
],
"title": "tcp: Correct signedness in skb remaining space calculation",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38463",
"datePublished": "2025-07-25T15:27:45.975Z",
"dateReserved": "2025-04-16T04:51:24.020Z",
"dateUpdated": "2025-07-28T04:23:11.023Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-38463\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-07-25T16:15:32.253\",\"lastModified\":\"2025-07-29T14:14:55.157\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ntcp: Correct signedness in skb remaining space calculation\\n\\nSyzkaller reported a bug [1] where sk-\u003esk_forward_alloc can overflow.\\n\\nWhen we send data, if an skb exists at the tail of the write queue, the\\nkernel will attempt to append the new data to that skb. However, the code\\nthat checks for available space in the skb is flawed:\\n\u0027\u0027\u0027\\ncopy = size_goal - skb-\u003elen\\n\u0027\u0027\u0027\\n\\nThe types of the variables involved are:\\n\u0027\u0027\u0027\\ncopy: ssize_t (s64 on 64-bit systems)\\nsize_goal: int\\nskb-\u003elen: unsigned int\\n\u0027\u0027\u0027\\n\\nDue to C\u0027s type promotion rules, the signed size_goal is converted to an\\nunsigned int to match skb-\u003elen before the subtraction. The result is an\\nunsigned int.\\n\\nWhen this unsigned int result is then assigned to the s64 copy variable,\\nit is zero-extended, preserving its non-negative value. Consequently, copy\\nis always \u003e= 0.\\n\\nAssume we are sending 2GB of data and size_goal has been adjusted to a\\nvalue smaller than skb-\u003elen. The subtraction will result in copy holding a\\nvery large positive integer. In the subsequent logic, this large value is\\nused to update sk-\u003esk_forward_alloc, which can easily cause it to overflow.\\n\\nThe syzkaller reproducer uses TCP_REPAIR to reliably create this\\ncondition. However, this can also occur in real-world scenarios. The\\ntcp_bound_to_half_wnd() function can also reduce size_goal to a small\\nvalue. This would cause the subsequent tcp_wmem_schedule() to set\\nsk-\u003esk_forward_alloc to a value close to INT_MAX. Further memory\\nallocation requests would then cause sk_forward_alloc to wrap around and\\nbecome negative.\\n\\n[1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: Correcto signado en el c\u00e1lculo del espacio restante de skb Syzkaller inform\u00f3 de un error [1] en el que sk-\u0026gt;sk_forward_alloc puede desbordarse. Al enviar datos, si existe un skb al final de la cola de escritura, el kernel intentar\u00e1 a\u00f1adir los nuevos datos a ese skb. Sin embargo, el c\u00f3digo que comprueba el espacio disponible en el skb presenta un fallo: \u0027\u0027\u0027 copy = size_goal - skb-\u0026gt;len \u0027\u0027\u0027 Los tipos de las variables implicadas son: \u0027\u0027\u0027 copy: ssize_t (s64 en sistemas de 64 bits) size_goal: int skb-\u0026gt;len: unsigned int \u0027\u0027\u0027 Debido a las reglas de promoci\u00f3n de tipos de C, el signed size_goal se convierte en un unsigned int para que coincida con skb-\u0026gt;len antes de la resta. El resultado es un unsigned int. Cuando este resultado entero sin signo se asigna a la variable de copia s64, se extiende a cero, conservando su valor no negativo. Por lo tanto, la copia siempre es \u0026gt;= 0. Supongamos que enviamos 2 GB de datos y que size_goal se ha ajustado a un valor menor que skb-\u0026gt;len. La resta har\u00e1 que la copia contenga un entero positivo muy grande. En la l\u00f3gica subsiguiente, este valor alto se utiliza para actualizar sk-\u0026gt;sk_forward_alloc, lo que puede provocar f\u00e1cilmente un desbordamiento. El reproductor syzkaller utiliza TCP_REPAIR para crear esta condici\u00f3n de forma fiable. Sin embargo, esto tambi\u00e9n puede ocurrir en situaciones reales. La funci\u00f3n tcp_bound_to_half_wnd() tambi\u00e9n puede reducir size_goal a un valor peque\u00f1o. Esto provocar\u00eda que la funci\u00f3n tcp_wmem_schedule() posterior estableciera sk-\u0026gt;sk_forward_alloc en un valor cercano a INT_MAX. Las solicitudes de asignaci\u00f3n de memoria adicionales har\u00edan que sk_forward_alloc se repita y se vuelva negativo. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/62e6160cfb5514787bda833d466509edc38fde23\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/81373cd1d72d87c7d844d4454a526b8f53e72d00\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/9f164fa6bb09fbcc60fa5c3ff551ce9eec1befd7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d3a5f2871adc0c61c61869f37f3e697d97f03d8c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…