CVE-2022-49998
Estado: ModificadaMedia (5.5)—
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix locking in rxrpc's sendmsg
Fix three bugs in the rxrpc's sendmsg implementation:
Thinking on this some more, it might make sense to have different locks for sendmsg() and recvmsg(). There's probably no need to make recvmsg() wait for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating that a call is dead before a sendmsg() to that call returns - but that can currently happen anyway.
Without fix (2), something like the following can be induced:
[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]
Detalles técnicos trazas, registros y código del informe original
(1) rxrpc_new_client_call() should release the socket lock when returning
an error from rxrpc_get_call_slot().
(2) rxrpc_wait_for_tx_window_intr() will return without the call mutex
held in the event that we're interrupted by a signal whilst waiting
for tx space on the socket or relocking the call mutex afterwards.
Fix this by: (a) moving the unlock/lock of the call mutex up to
rxrpc_send_data() such that the lock is not held around all of
rxrpc_wait_for_tx_window*() and (b) indicating to higher callers
whether we're return with the lock dropped. Note that this means
recvmsg() will not block on this call whilst we're waiting.
(3) After dropping and regaining the call mutex, rxrpc_send_data() needs
to go and recheck the state of the tx_pending buffer and the
tx_total_len check in case we raced with another sendmsg() on the same
call.
WARNING: bad unlock balance detected!
5.16.0-rc6-syzkaller #0 Not tainted
-------------------------------------
syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
but there are no more locks to release!
other info that might help us debug this:
no locks held by syz-executor011/3597.
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
__lock_release kernel/locking/lockdep.c:5306 [inline]
lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
__mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900
rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
___sys_sendmsg+0xf3/0x170 net/socket.c:2463
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xaeCVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Puntuación base: 5.5
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.19%
- Percentil entre todas las CVEs puntuadas: 8
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
CWE
- CWE-667
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2022-49998",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 1.8
},
{
"type": "Primary",
"source": "nvd@nist.gov",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 5.5,
"attackVector": "LOCAL",
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"integrityImpact": "NONE",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "NONE"
},
"impactScore": 3.6,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "bc5e3a546d553e5223851fc199e69040eb70f68b",
"lessThan": "79e2ca7aa96e80961828ab6312264633b66183cc",
"versionType": "git"
},
{
"status": "affected",
"version": "bc5e3a546d553e5223851fc199e69040eb70f68b",
"lessThan": "2bc769b8edb158be7379d15f36e23d66cf850053",
"versionType": "git"
},
{
"status": "affected",
"version": "bc5e3a546d553e5223851fc199e69040eb70f68b",
"lessThan": "091dc91e119fdd61432347231724f4e861c6b465",
"versionType": "git"
},
{
"status": "affected",
"version": "bc5e3a546d553e5223851fc199e69040eb70f68b",
"lessThan": "b0f571ecd7943423c25947439045f0d352ca3dbf",
"versionType": "git"
}
],
"programFiles": [
"net/rxrpc/call_object.c",
"net/rxrpc/sendmsg.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "4.15"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "4.15",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.10.140",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.64",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "5.19.6",
"versionType": "semver",
"lessThanOrEqual": "5.19.*"
},
{
"status": "unaffected",
"version": "6.0",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"net/rxrpc/call_object.c",
"net/rxrpc/sendmsg.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2025-06-18T11:15:27.557",
"references": [
{
"url": "https://git.kernel.org/stable/c/091dc91e119fdd61432347231724f4e861c6b465",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/2bc769b8edb158be7379d15f36e23d66cf850053",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/79e2ca7aa96e80961828ab6312264633b66183cc",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/b0f571ecd7943423c25947439045f0d352ca3dbf",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Modified",
"weaknesses": [
{
"type": "Primary",
"source": "nvd@nist.gov",
"description": [
{
"lang": "en",
"value": "CWE-667"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix locking in rxrpc's sendmsg\n\nFix three bugs in the rxrpc's sendmsg implementation:\n\n (1) rxrpc_new_client_call() should release the socket lock when returning\n an error from rxrpc_get_call_slot().\n\n (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex\n held in the event that we're interrupted by a signal whilst waiting\n for tx space on the socket or relocking the call mutex afterwards.\n\n Fix this by: (a) moving the unlock/lock of the call mutex up to\n rxrpc_send_data() such that the lock is not held around all of\n rxrpc_wait_for_tx_window*() and (b) indicating to higher callers\n whether we're return with the lock dropped. Note that this means\n recvmsg() will not block on this call whilst we're waiting.\n\n (3) After dropping and regaining the call mutex, rxrpc_send_data() needs\n to go and recheck the state of the tx_pending buffer and the\n tx_total_len check in case we raced with another sendmsg() on the same\n call.\n\nThinking on this some more, it might make sense to have different locks for\nsendmsg() and recvmsg(). There's probably no need to make recvmsg() wait\nfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating\nthat a call is dead before a sendmsg() to that call returns - but that can\ncurrently happen anyway.\n\nWithout fix (2), something like the following can be induced:\n\n\tWARNING: bad unlock balance detected!\n\t5.16.0-rc6-syzkaller #0 Not tainted\n\t-------------------------------------\n\tsyz-executor011/3597 is trying to release lock (&call->user_mutex) at:\n\t[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\tbut there are no more locks to release!\n\n\tother info that might help us debug this:\n\tno locks held by syz-executor011/3597.\n\t...\n\tCall Trace:\n\t <TASK>\n\t __dump_stack lib/dump_stack.c:88 [inline]\n\t dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n\t print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]\n\t __lock_release kernel/locking/lockdep.c:5306 [inline]\n\t lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657\n\t __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900\n\t rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\t rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561\n\t sock_sendmsg_nosec net/socket.c:704 [inline]\n\t sock_sendmsg+0xcf/0x120 net/socket.c:724\n\t ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n\t ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n\t __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n\t do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n\t do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n\t entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementación de sendmsg de rxrpc: (1) rxrpc_new_client_call() debería liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornará sin el mutex de llamada retenido en caso de que seamos interrumpidos por una señal mientras esperamos espacio de transmisión en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloqueará en esta llamada mientras esperamos. (3) Después de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del búfer tx_pending y la comprobación de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pensándolo bien, podría tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada está inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la corrección (2), se puede inducir algo como lo siguiente: ¡ADVERTENCIA: se detectó un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 está intentando liberar el bloqueo (&call->user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 ¡pero no hay más bloqueos para liberar! Otra información que podría ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en línea] __lock_release kernel/locking/lockdep.c:5306 [en línea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]"
}
],
"lastModified": "2026-08-04T10:18:02.667",
"configurations": [
{
"nodes": [
{
"negate": false,
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "C05E823D-7C3B-40D6-B6AC-C0763D3C390D",
"versionEndExcluding": "5.10.140",
"versionStartIncluding": "4.15"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "292F3687-ADC2-4F3D-9710-3BCAD11A52BE",
"versionEndExcluding": "5.15.64",
"versionStartIncluding": "5.11"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "89E99903-E16D-475D-954B-2BAC46C98262",
"versionEndExcluding": "5.19.6",
"versionStartIncluding": "5.16"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.0:rc1:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "E8BD11A3-8643-49B6-BADE-5029A0117325"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.0:rc2:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "5F0AD220-F6A9-4012-8636-155F1B841FAD"
}
],
"operator": "OR"
}
]
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}