CVE-2022-49215

{"id": "CVE-2022-49215", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 4.7, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.0}]}, "published": "2025-02-26T07:00:58.590", "references": [{"url": "https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-362"}, {"lang": "en", "value": "CWE-476"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix race at socket teardown\n\nFix a race in the xsk socket teardown code that can lead to a NULL pointer\ndereference splat. The current xsk unbind code in xsk_unbind_dev() starts by\nsetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any\nNAPI processing to terminate using synchronize_net(). After that, the release\ncode starts to tear down the socket state and free allocated memory.\n\n BUG: kernel NULL pointer dereference, address: 00000000000000c0\n PGD 8000000932469067 P4D 8000000932469067 PUD 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2\n Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015\n RIP: 0010:__xsk_sendmsg+0x2c/0x690\n [...]\n RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258\n RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800\n RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800\n R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000\n FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0\n Call Trace:\n <TASK>\n ? aa_sk_perm+0x43/0x1b0\n xsk_sendmsg+0xf0/0x110\n sock_sendmsg+0x65/0x70\n __sys_sendto+0x113/0x190\n ? debug_smp_processor_id+0x17/0x20\n ? fpregs_assert_state_consistent+0x23/0x50\n ? exit_to_user_mode_prepare+0xa5/0x1d0\n __x64_sys_sendto+0x29/0x30\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThere are two problems with the current code. First, setting xs->dev to NULL\nbefore waiting for all users to stop using the socket is not correct. The\nentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()\nare all guarded by a test that xs->state is in the state XSK_BOUND and if not,\nit returns right away. But one process might have passed this test but still\nhave not gotten to the point in which it uses xs->dev in the code. In this\ninterim, a second process executing xsk_unbind_dev() might have set xs->dev to\nNULL which will lead to a crash for the first process. The solution here is\njust to get rid of this NULL assignment since it is not used anymore. Before\ncommit 42fddcc7c64b (\"xsk: use state member for socket synchronization\"),\nxs->dev was the gatekeeper to admit processes into the data plane functions,\nbut it was replaced with the state variable xs->state in the aforementioned\ncommit.\n\nThe second problem is that synchronize_net() does not wait for any process in\nxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the\nstate they rely on might be cleaned up prematurely. This can happen when the\nnotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().\nSolve this by extending the RCU critical region from just the ndo_xsk_wakeup\nto the whole functions mentioned above, so that both the test of xs->state ==\nXSK_BOUND and the last use of any member of xs is covered by the RCU critical\nsection. This will guarantee that when synchronize_net() completes, there will\nbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and\nstate can be cleaned up safely. Note that we need to drop the RCU lock for the\nskb xmit path as it uses functions that might sleep. Due to this, we have to\nretest the xs->state after we grab the mutex that protects the skb xmit code\nfrom, among a number of things, an xsk_unbind_dev() being executed from the\nnotifier at the same time."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corregir ejecuci\u00f3n en el desmontaje del socket Corrige una ejecuci\u00f3n en el c\u00f3digo de desmontaje del socket xsk que puede provocar un splat de desreferencia de puntero NULL. El c\u00f3digo de desvinculaci\u00f3n xsk actual en xsk_unbind_dev() comienza estableciendo xs-&gt;state en XSK_UNBOUND, establece xs-&gt;dev en NULL y luego espera a que finalice cualquier procesamiento NAPI utilizandosynchronous_net(). Despu\u00e9s de eso, el c\u00f3digo de lanzamiento comienza a desmantelar el estado del socket y a liberar la memoria asignada. ERROR: desreferencia de puntero NULL del n\u00facleo, direcci\u00f3n: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Contaminado: GI 5.16.0+ #2 Nombre del hardware: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 09/03/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 00000000000000000 RBX: 00000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Seguimiento de llamadas: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Hay dos problemas con el c\u00f3digo actual. Primero, establecer xs-&gt;dev en NULL antes de esperar a que todos los usuarios dejen de usar el socket no es correcto. La entrada a las funciones del plano de datos xsk_poll(), xsk_sendmsg() y xsk_recvmsg() est\u00e1n todas protegidas por una prueba de que xs-&gt;state est\u00e1 en el estado XSK_BOUND y, si no, regresa de inmediato. Pero un proceso podr\u00eda haber pasado esta prueba pero a\u00fan no haber llegado al punto en el que usa xs-&gt;dev en el c\u00f3digo. Mientras tanto, un segundo proceso que ejecuta xsk_unbind_dev() podr\u00eda haber establecido xs-&gt;dev en NULL, lo que provocar\u00e1 un bloqueo para el primer proceso. La soluci\u00f3n aqu\u00ed es simplemente deshacerse de esta asignaci\u00f3n NULL ya que ya no se usa. Antes de el commit 42fddcc7c64b (\"xsk: usar miembro de estado para sincronizaci\u00f3n de socket\"), xs-&gt;dev era el guardi\u00e1n para admitir procesos en las funciones del plano de datos, pero fue reemplazado por la variable de estado xs-&gt;state en el commit mencionada anteriormente. El segundo problema es quesynchronous_net() no espera a que se complete ning\u00fan proceso en xsk_poll(), xsk_sendmsg() o xsk_recvmsg(), lo que significa que el estado en el que se basan podr\u00eda limpiarse prematuramente. Esto puede suceder cuando se llama al notificador (por ejemplo, al descargar el controlador) ya que utiliza xsk_unbind_dev(). Resuelva esto extendiendo la regi\u00f3n cr\u00edtica de RCU desde solo ndo_xsk_wakeup a todas las funciones mencionadas anteriormente, de modo que tanto la prueba de xs-&gt;state == XSK_BOUND como el \u00faltimo uso de cualquier miembro de xs est\u00e9n cubiertos por la secci\u00f3n cr\u00edtica de RCU. Esto garantizar\u00e1 que cuando se completesynchronous_net(), no habr\u00e1 procesos restantes ejecutando xsk_poll(), xsk_sendmsg() o xsk_recvmsg() y el estado se puede limpiar de forma segura. Tenga en cuenta que debemos eliminar el bloqueo de RCU para la ruta de transmisi\u00f3n de skb, ya que utiliza funciones que podr\u00edan estar inactivas. Debido a esto, tenemos que volver a probar xs-&gt;state despu\u00e9s de obtener el mutex que protege el c\u00f3digo xmit de skb de, entre varias cosas, un xsk_unbind_dev() que se ejecuta desde el notificador al mismo tiempo."}], "lastModified": "2025-03-18T19:32:25.867", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "6B796901-86B9-450D-BE47-916285FBDF61", "versionEndExcluding": "5.15.33", "versionStartIncluding": "5.4"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "20C43679-0439-405A-B97F-685BEE50613B", "versionEndExcluding": "5.16.19", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "210C679C-CF84-44A3-8939-E629C87E54BF", "versionEndExcluding": "5.17.2", "versionStartIncluding": "5.17"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}