{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2021-47303", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-05-21T13:27:52.132Z", "datePublished": "2024-05-21T14:35:24.027Z", "dateUpdated": "2024-11-04T12:03:19.549Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T12:03:19.549Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Track subprog poke descriptors correctly and fix use-after-free\n\nSubprograms are calling map_poke_track(), but on program release there is no\nhook to call map_poke_untrack(). However, on program release, the aux memory\n(and poke descriptor table) is freed even though we still have a reference to\nit in the element list of the map aux data. When we run map_poke_run(), we then\nend up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():\n\n [...]\n [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e\n [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337\n [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399\n [ 402.824715] Call Trace:\n [ 402.824719] dump_stack+0x93/0xc2\n [ 402.824727] print_address_description.constprop.0+0x1a/0x140\n [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824744] kasan_report.cold+0x7c/0xd8\n [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824757] prog_array_map_poke_run+0xc2/0x34e\n [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0\n [...]\n\nThe elements concerned are walked as follows:\n\n for (i = 0; i < elem->aux->size_poke_tab; i++) {\n poke = &elem->aux->poke_tab[i];\n [...]\n\nThe access to size_poke_tab is a 4 byte read, verified by checking offsets\nin the KASAN dump:\n\n [ 402.825004] The buggy address belongs to the object at ffff8881905a7800\n which belongs to the cache kmalloc-1k of size 1024\n [ 402.825008] The buggy address is located 320 bytes inside of\n 1024-byte region [ffff8881905a7800, ffff8881905a7c00)\n\nThe pahole output of bpf_prog_aux:\n\n struct bpf_prog_aux {\n [...]\n /* --- cacheline 5 boundary (320 bytes) --- */\n u32 size_poke_tab; /* 320 4 */\n [...]\n\nIn general, subprograms do not necessarily manage their own data structures.\nFor example, BTF func_info and linfo are just pointers to the main program\nstructure. This allows reference counting and cleanup to be done on the latter\nwhich simplifies their management a bit. The aux->poke_tab struct, however,\ndid not follow this logic. The initial proposed fix for this use-after-free\nbug further embedded poke data tracking into the subprogram with proper\nreference counting. However, Daniel and Alexei questioned why we were treating\nthese objects special; I agree, its unnecessary. The fix here removes the per\nsubprogram poke table allocation and map tracking and instead simply points\nthe aux->poke_tab pointer at the main programs poke table. This way, map\ntracking is simplified to the main program and we do not need to manage them\nper subprogram.\n\nThis also means, bpf_prog_free_deferred(), which unwinds the program reference\ncounting and kfrees objects, needs to ensure that we don't try to double free\nthe poke_tab when free'ing the subprog structures. This is easily solved by\nNULL'ing the poke_tab pointer. The second detail is to ensure that per\nsubprogram JIT logic only does fixups on poke_tab[] entries it owns. To do\nthis, we add a pointer in the poke structure to point at the subprogram value\nso JITs can easily check while walking the poke_tab structure if the current\nentry belongs to the current program. The aux pointer is stable and therefore\nsuitable for such comparison. On the jit_subprogs() error path, we omit\ncleaning up the poke->aux field because these are only ever referenced from\nthe JIT side, but on error we will never make it to the JIT, so its fine to\nleave them dangling. Removing these pointers would complicate the error path\nfor no reason. However, we do need to untrack all poke descriptors from the\nmain program as otherwise they could race with the freeing of JIT memory from\nthe subprograms. Lastly, a748c6975dea3 (\"bpf: propagate poke des\n---truncated---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/x86/net/bpf_jit_comp.c", "include/linux/bpf.h", "kernel/bpf/core.c", "kernel/bpf/verifier.c"], "versions": [{"version": "a748c6975dea", "lessThan": "a9f36bf3613c", "status": "affected", "versionType": "git"}, {"version": "a748c6975dea", "lessThan": "599148d40366", "status": "affected", "versionType": "git"}, {"version": "a748c6975dea", "lessThan": "f263a81451c1", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/x86/net/bpf_jit_comp.c", "include/linux/bpf.h", "kernel/bpf/core.c", "kernel/bpf/verifier.c"], "versions": [{"version": "5.10", "status": "affected"}, {"version": "0", "lessThan": "5.10", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.53", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.13.5", "lessThanOrEqual": "5.13.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.14", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/a9f36bf3613c65cb587c70fac655c775d911409b"}, {"url": "https://git.kernel.org/stable/c/599148d40366bd5d1d504a3a8fcd65e21107e500"}, {"url": "https://git.kernel.org/stable/c/f263a81451c12da5a342d90572e317e611846f2c"}], "title": "bpf: Track subprog poke descriptors correctly and fix use-after-free", "x_generator": {"engine": "bippy-9e1c9544281a"}}, "adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2021-47303", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "version": "2.0.3", "timestamp": "2024-05-29T18:50:53.751322Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-04T17:15:06.921Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T05:32:08.452Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/a9f36bf3613c65cb587c70fac655c775d911409b", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/599148d40366bd5d1d504a3a8fcd65e21107e500", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/f263a81451c12da5a342d90572e317e611846f2c", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/a9f36bf3613c65cb587c70fac655c775d911409b", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/599148d40366bd5d1d504a3a8fcd65e21107e500", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/f263a81451c12da5a342d90572e317e611846f2c", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T05:32:08.452Z"}}, {"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2021-47303", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "version": "2.0.3", "timestamp": "2024-05-29T18:50:53.751322Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-29T18:50:58.742Z"}, "title": "CISA ADP Vulnrichment"}], "cna": {"title": "bpf: Track subprog poke descriptors correctly and fix use-after-free", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "a748c6975dea", "lessThan": "a9f36bf3613c", "versionType": "git"}, {"status": "affected", "version": "a748c6975dea", "lessThan": "599148d40366", "versionType": "git"}, {"status": "affected", "version": "a748c6975dea", "lessThan": "f263a81451c1", "versionType": "git"}], "programFiles": ["arch/x86/net/bpf_jit_comp.c", "include/linux/bpf.h", "kernel/bpf/core.c", "kernel/bpf/verifier.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.10"}, {"status": "unaffected", "version": "0", "lessThan": "5.10", "versionType": "custom"}, {"status": "unaffected", "version": "5.10.53", "versionType": "custom", "lessThanOrEqual": "5.10.*"}, {"status": "unaffected", "version": "5.13.5", "versionType": "custom", "lessThanOrEqual": "5.13.*"}, {"status": "unaffected", "version": "5.14", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["arch/x86/net/bpf_jit_comp.c", "include/linux/bpf.h", "kernel/bpf/core.c", "kernel/bpf/verifier.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/a9f36bf3613c65cb587c70fac655c775d911409b"}, {"url": "https://git.kernel.org/stable/c/599148d40366bd5d1d504a3a8fcd65e21107e500"}, {"url": "https://git.kernel.org/stable/c/f263a81451c12da5a342d90572e317e611846f2c"}], "x_generator": {"engine": "bippy-a5840b7849dd"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Track subprog poke descriptors correctly and fix use-after-free\n\nSubprograms are calling map_poke_track(), but on program release there is no\nhook to call map_poke_untrack(). However, on program release, the aux memory\n(and poke descriptor table) is freed even though we still have a reference to\nit in the element list of the map aux data. When we run map_poke_run(), we then\nend up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():\n\n [...]\n [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e\n [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337\n [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399\n [ 402.824715] Call Trace:\n [ 402.824719] dump_stack+0x93/0xc2\n [ 402.824727] print_address_description.constprop.0+0x1a/0x140\n [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824744] kasan_report.cold+0x7c/0xd8\n [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824757] prog_array_map_poke_run+0xc2/0x34e\n [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0\n [...]\n\nThe elements concerned are walked as follows:\n\n for (i = 0; i < elem->aux->size_poke_tab; i++) {\n poke = &elem->aux->poke_tab[i];\n [...]\n\nThe access to size_poke_tab is a 4 byte read, verified by checking offsets\nin the KASAN dump:\n\n [ 402.825004] The buggy address belongs to the object at ffff8881905a7800\n which belongs to the cache kmalloc-1k of size 1024\n [ 402.825008] The buggy address is located 320 bytes inside of\n 1024-byte region [ffff8881905a7800, ffff8881905a7c00)\n\nThe pahole output of bpf_prog_aux:\n\n struct bpf_prog_aux {\n [...]\n /* --- cacheline 5 boundary (320 bytes) --- */\n u32 size_poke_tab; /* 320 4 */\n [...]\n\nIn general, subprograms do not necessarily manage their own data structures.\nFor example, BTF func_info and linfo are just pointers to the main program\nstructure. This allows reference counting and cleanup to be done on the latter\nwhich simplifies their management a bit. The aux->poke_tab struct, however,\ndid not follow this logic. The initial proposed fix for this use-after-free\nbug further embedded poke data tracking into the subprogram with proper\nreference counting. However, Daniel and Alexei questioned why we were treating\nthese objects special; I agree, its unnecessary. The fix here removes the per\nsubprogram poke table allocation and map tracking and instead simply points\nthe aux->poke_tab pointer at the main programs poke table. This way, map\ntracking is simplified to the main program and we do not need to manage them\nper subprogram.\n\nThis also means, bpf_prog_free_deferred(), which unwinds the program reference\ncounting and kfrees objects, needs to ensure that we don't try to double free\nthe poke_tab when free'ing the subprog structures. This is easily solved by\nNULL'ing the poke_tab pointer. The second detail is to ensure that per\nsubprogram JIT logic only does fixups on poke_tab[] entries it owns. To do\nthis, we add a pointer in the poke structure to point at the subprogram value\nso JITs can easily check while walking the poke_tab structure if the current\nentry belongs to the current program. The aux pointer is stable and therefore\nsuitable for such comparison. On the jit_subprogs() error path, we omit\ncleaning up the poke->aux field because these are only ever referenced from\nthe JIT side, but on error we will never make it to the JIT, so its fine to\nleave them dangling. Removing these pointers would complicate the error path\nfor no reason. However, we do need to untrack all poke descriptors from the\nmain program as otherwise they could race with the freeing of JIT memory from\nthe subprograms. Lastly, a748c6975dea3 (\"bpf: propagate poke des\n---truncated---"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-05-29T05:05:36.426Z"}}}, "cveMetadata": {"cveId": "CVE-2021-47303", "state": "PUBLISHED", "dateUpdated": "2024-08-04T05:32:08.452Z", "dateReserved": "2024-05-21T13:27:52.132Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-05-21T14:35:24.027Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Track subprog poke descriptors correctly and fix use-after-free\n\nSubprograms are calling map_poke_track(), but on program release there is no\nhook to call map_poke_untrack(). However, on program release, the aux memory\n(and poke descriptor table) is freed even though we still have a reference to\nit in the element list of the map aux data. When we run map_poke_run(), we then\nend up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():\n\n [...]\n [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e\n [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337\n [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399\n [ 402.824715] Call Trace:\n [ 402.824719] dump_stack+0x93/0xc2\n [ 402.824727] print_address_description.constprop.0+0x1a/0x140\n [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824744] kasan_report.cold+0x7c/0xd8\n [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e\n [ 402.824757] prog_array_map_poke_run+0xc2/0x34e\n [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0\n [...]\n\nThe elements concerned are walked as follows:\n\n for (i = 0; i < elem->aux->size_poke_tab; i++) {\n poke = &elem->aux->poke_tab[i];\n [...]\n\nThe access to size_poke_tab is a 4 byte read, verified by checking offsets\nin the KASAN dump:\n\n [ 402.825004] The buggy address belongs to the object at ffff8881905a7800\n which belongs to the cache kmalloc-1k of size 1024\n [ 402.825008] The buggy address is located 320 bytes inside of\n 1024-byte region [ffff8881905a7800, ffff8881905a7c00)\n\nThe pahole output of bpf_prog_aux:\n\n struct bpf_prog_aux {\n [...]\n /* --- cacheline 5 boundary (320 bytes) --- */\n u32 size_poke_tab; /* 320 4 */\n [...]\n\nIn general, subprograms do not necessarily manage their own data structures.\nFor example, BTF func_info and linfo are just pointers to the main program\nstructure. This allows reference counting and cleanup to be done on the latter\nwhich simplifies their management a bit. The aux->poke_tab struct, however,\ndid not follow this logic. The initial proposed fix for this use-after-free\nbug further embedded poke data tracking into the subprogram with proper\nreference counting. However, Daniel and Alexei questioned why we were treating\nthese objects special; I agree, its unnecessary. The fix here removes the per\nsubprogram poke table allocation and map tracking and instead simply points\nthe aux->poke_tab pointer at the main programs poke table. This way, map\ntracking is simplified to the main program and we do not need to manage them\nper subprogram.\n\nThis also means, bpf_prog_free_deferred(), which unwinds the program reference\ncounting and kfrees objects, needs to ensure that we don't try to double free\nthe poke_tab when free'ing the subprog structures. This is easily solved by\nNULL'ing the poke_tab pointer. The second detail is to ensure that per\nsubprogram JIT logic only does fixups on poke_tab[] entries it owns. To do\nthis, we add a pointer in the poke structure to point at the subprogram value\nso JITs can easily check while walking the poke_tab structure if the current\nentry belongs to the current program. The aux pointer is stable and therefore\nsuitable for such comparison. On the jit_subprogs() error path, we omit\ncleaning up the poke->aux field because these are only ever referenced from\nthe JIT side, but on error we will never make it to the JIT, so its fine to\nleave them dangling. Removing these pointers would complicate the error path\nfor no reason. However, we do need to untrack all poke descriptors from the\nmain program as otherwise they could race with the freeing of JIT memory from\nthe subprograms. Lastly, a748c6975dea3 (\"bpf: propagate poke des\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: realiza un seguimiento correcto de los descriptores de poke del subprog y corrige el use-after-free. Los subprogramas llaman a map_poke_track(), pero en el lanzamiento del programa no hay ning\u00fan enlace para llamar a map_poke_untrack(). Sin embargo, al lanzar el programa, la memoria auxiliar (y la tabla de descriptores de inserci\u00f3n) se liberan aunque todav\u00eda tengamos una referencia a ella en la lista de elementos de los datos auxiliares del mapa. Cuando ejecutamos map_poke_run(), terminamos accediendo a la memoria liberada, lo que activa KASAN en prog_array_map_poke_run(): [...] [402.824689] ERROR: KASAN: use-after-free en prog_array_map_poke_run+0xc2/0x34e [402.824698] Lectura del tama\u00f1o 4 en la direcci\u00f3n ffff8881905a7940 mediante la tarea hubble-fgs/4337 [402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Contaminado: GI 5.12.0+ #399 [402.824715] Seguimiento de llamadas: [402.824719] x93/ 0xc2 [402.824727] print_address_description.constprop.0+0x1a/0x140 [402.824736]? prog_array_map_poke_run+0xc2/0x34e [402.824740]? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] Los elementos en cuesti\u00f3n se recorren de la siguiente manera: for (i = 0; i &lt; elem-&gt; aux-&gt;tama\u00f1o_poke_tab; i++) { empujar = &amp;elem-&gt;aux-&gt;poke_tab[i]; [...] El acceso a size_poke_tab es una lectura de 4 bytes, verificada verificando las compensaciones en el volcado de KASAN: [402.825004] La direcci\u00f3n con errores pertenece al objeto en ffff8881905a7800 que pertenece al cach\u00e9 kmalloc-1k de tama\u00f1o 1024 [402.825008] La direcci\u00f3n con errores se encuentra a 320 bytes dentro de una regi\u00f3n de 1024 bytes [ffff8881905a7800, ffff8881905a7c00) La salida de error de bpf_prog_aux: struct bpf_prog_aux { [...] /* --- l\u00edmite de cacheline 5 (320 bytes) --- */ u32 tama\u00f1o_poke_tab; /* 320 4 */ [...] En general, los subprogramas no necesariamente gestionan sus propias estructuras de datos. Por ejemplo, BTF func_info y linfo son s\u00f3lo punteros a la estructura principal del programa. Esto permite realizar un recuento de referencias y una sanitizaci\u00f3n de estos \u00faltimos, lo que simplifica un poco su gesti\u00f3n. La estructura aux-&gt;poke_tab, sin embargo, no sigui\u00f3 esta l\u00f3gica. La soluci\u00f3n inicial propuesta para este error de use-after-free incorpor\u00f3 a\u00fan m\u00e1s el seguimiento de datos de inserci\u00f3n en el subprograma con un recuento de referencias adecuado. Sin embargo, Daniel y Alexei se preguntaron por qu\u00e9 trat\u00e1bamos a estos objetos de manera especial; Estoy de acuerdo, es innecesario. La soluci\u00f3n aqu\u00ed elimina la asignaci\u00f3n de la tabla de poke por subprograma y el seguimiento del mapa y, en su lugar, simplemente apunta el puntero aux-&gt;poke_tab a la tabla de poke del programa principal. De esta manera, el seguimiento de mapas se simplifica al programa principal y no necesitamos gestionarlos por subprograma. Esto tambi\u00e9n significa que bpf_prog_free_deferred(), que desenrolla el recuento de referencias del programa y libera objetos, debe garantizar que no intentemos liberar dos veces el poke_tab al liberar las estructuras de subprog. Esto se resuelve f\u00e1cilmente haciendo NULL en el puntero poke_tab. El segundo detalle es garantizar que la l\u00f3gica JIT por subprograma solo realice correcciones en las entradas poke_tab[] que posee. Para hacer esto, agregamos un puntero en la estructura poke para se\u00f1alar el valor del subprograma para que los JIT puedan verificar f\u00e1cilmente mientras recorren la estructura poke_tab si la entrada actual pertenece al programa actual. El puntero auxiliar es estable y, por tanto, adecuado para dicha comparaci\u00f3n. ---truncado---"}], "id": "CVE-2021-47303", "lastModified": "2024-05-21T16:54:26.047", "metrics": {}, "published": "2024-05-21T15:15:18.037", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/599148d40366bd5d1d504a3a8fcd65e21107e500"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a9f36bf3613c65cb587c70fac655c775d911409b"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/f263a81451c12da5a342d90572e317e611846f2c"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: bpf: Track subprog poke descriptors correctly and fix use-after-free", "id": "2282480", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2282480"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.4", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-416", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbpf: Track subprog poke descriptors correctly and fix use-after-free\nSubprograms are calling map_poke_track(), but on program release there is no\nhook to call map_poke_untrack(). However, on program release, the aux memory\n(and poke descriptor table) is freed even though we still have a reference to\nit in the element list of the map aux data. When we run map_poke_run(), we then\nend up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():\n[...]\n[ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e\n[ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337\n[ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399\n[ 402.824715] Call Trace:\n[ 402.824719] dump_stack+0x93/0xc2\n[ 402.824727] print_address_description.constprop.0+0x1a/0x140\n[ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e\n[ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e\n[ 402.824744] kasan_report.cold+0x7c/0xd8\n[ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e\n[ 402.824757] prog_array_map_poke_run+0xc2/0x34e\n[ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0\n[...]\nThe elements concerned are walked as follows:\nfor (i = 0; i < elem->aux->size_poke_tab; i++) {\npoke = &elem->aux->poke_tab[i];\n[...]\nThe access to size_poke_tab is a 4 byte read, verified by checking offsets\nin the KASAN dump:\n[ 402.825004] The buggy address belongs to the object at ffff8881905a7800\nwhich belongs to the cache kmalloc-1k of size 1024\n[ 402.825008] The buggy address is located 320 bytes inside of\n1024-byte region [ffff8881905a7800, ffff8881905a7c00)\nThe pahole output of bpf_prog_aux:\nstruct bpf_prog_aux {\n[...]\n/* --- cacheline 5 boundary (320 bytes) --- */\nu32 size_poke_tab; /* 320 4 */\n[...]\nIn general, subprograms do not necessarily manage their own data structures.\nFor example, BTF func_info and linfo are just pointers to the main program\nstructure. This allows reference counting and cleanup to be done on the latter\nwhich simplifies their management a bit. The aux->poke_tab struct, however,\ndid not follow this logic. The initial proposed fix for this use-after-free\nbug further embedded poke data tracking into the subprogram with proper\nreference counting. However, Daniel and Alexei questioned why we were treating\nthese objects special; I agree, its unnecessary. The fix here removes the per\nsubprogram poke table allocation and map tracking and instead simply points\nthe aux->poke_tab pointer at the main programs poke table. This way, map\ntracking is simplified to the main program and we do not need to manage them\nper subprogram.\nThis also means, bpf_prog_free_deferred(), which unwinds the program reference\ncounting and kfrees objects, needs to ensure that we don't try to double free\nthe poke_tab when free'ing the subprog structures. This is easily solved by\nNULL'ing the poke_tab pointer. The second detail is to ensure that per\nsubprogram JIT logic only does fixups on poke_tab[] entries it owns. To do\nthis, we add a pointer in the poke structure to point at the subprogram value\nso JITs can easily check while walking the poke_tab structure if the current\nentry belongs to the current program. The aux pointer is stable and therefore\nsuitable for such comparison. On the jit_subprogs() error path, we omit\ncleaning up the poke->aux field because these are only ever referenced from\nthe JIT side, but on error we will never make it to the JIT, so its fine to\nleave them dangling. Removing these pointers would complicate the error path\nfor no reason. However, we do need to untrack all poke descriptors from the\nmain program as otherwise they could race with the freeing of JIT memory from\nthe subprograms. Lastly, a748c6975dea3 (\"bpf: propagate poke des\n---truncated---"], "name": "CVE-2021-47303", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-05-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2021-47303\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-47303\nhttps://lore.kernel.org/linux-cve-announce/2024052126-CVE-2021-47303-72dc@gregkh/T"], "threat_severity": "Low", "upstream_fix": "kernel 5.10.53, kernel 5.13.5, kernel 5.14"}