nvd-json-data-feeds/CVE-2024/CVE-2024-394xx/CVE-2024-39488.json

{
  "id": "CVE-2024-39488",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "published": "2024-07-10T08:15:11.003",
  "lastModified": "2024-07-11T13:05:54.930",
  "vulnStatus": "Awaiting Analysis",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY\n\nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes\nto bug_table entries, and as a result the last entry in a bug table will\nbe ignored, potentially leading to an unexpected panic(). All prior\nentries in the table will be handled correctly.\n\nThe arm64 ABI requires that struct fields of up to 8 bytes are\nnaturally-aligned, with padding added within a struct such that struct\nare suitably aligned within arrays.\n\nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:\n\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tsigned int      file_disp;\t// 4 bytes\n\t\tunsigned short  line;\t\t// 2 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t}\n\n... with 12 bytes total, requiring 4-byte alignment.\n\nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:\n\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t\t< implicit padding >\t\t// 2 bytes\n\t}\n\n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing\npadding, requiring 4-byte alginment.\n\nWhen we create a bug_entry in assembly, we align the start of the entry\nto 4 bytes, which implicitly handles padding for any prior entries.\nHowever, we do not align the end of the entry, and so when\nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding\nbytes.\n\nFor the main kernel image this is not a problem as find_bug() doesn't\ndepend on the trailing padding bytes when searching for entries:\n\n\tfor (bug = __start___bug_table; bug < __stop___bug_table; ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\treturn bug;\n\nHowever for modules, module_bug_finalize() depends on the trailing\nbytes when calculating the number of entries:\n\n\tmod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);\n\n... and as the last bug_entry lacks the necessary padding bytes, this entry\nwill not be counted, e.g. in the case of a single entry:\n\n\tsechdrs[i].sh_size == 6\n\tsizeof(struct bug_entry) == 8;\n\n\tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;\n\nConsequently module_find_bug() will miss the last bug_entry when it does:\n\n\tfor (i = 0; i < mod->num_bugs; ++i, ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\tgoto out;\n\n... which can lead to a kenrel panic due to an unhandled bug.\n\nThis can be demonstrated with the following module:\n\n\tstatic int __init buginit(void)\n\t{\n\t\tWARN(1, \"hello\\n\");\n\t\treturn 0;\n\t}\n\n\tstatic void __exit bugexit(void)\n\t{\n\t}\n\n\tmodule_init(buginit);\n\tmodule_exit(bugexit);\n\tMODULE_LICENSE(\"GPL\");\n\n... which will trigger a kernel panic when loaded:\n\n\t------------[ cut here ]------------\n\thello\n\tUnexpected kernel BRK exception at EL1\n\tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP\n\tModules linked in: hello(O+)\n\tCPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : buginit+0x18/0x1000 [hello]\n\tlr : buginit+0x18/0x1000 [hello]\n\tsp : ffff800080533ae0\n\tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000\n\tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58\n\tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0\n\tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006\n\tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720\n\tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312\n\tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8\n\tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000\n\tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0\n\tCall trace:\n\t buginit+0x18/0x1000 [hello]\n\t do_one_initcall+0x80/0x1c8\n\t do_init_module+0x60/0x218\n\t load_module+0x1ba4/0x1d70\n\t __do_sys_init_module+0x198/0x1d0\n\t __arm64_sys_init_module+0x1c/0x28\n\t invoke_syscall+0x48/0x114\n\t el0_svc\n---truncated---"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: arm64: asm-bug: agregue .align 2 al final de __BUG_ENTRY Cuando CONFIG_DEBUG_BUGVERBOSE=n, no agregamos los bytes de relleno necesarios a las entradas de bug_table y, como resultado, la \u00faltima entrada en una tabla de errores se ignorar\u00e1, lo que podr\u00eda provocar un p\u00e1nico inesperado(). Todas las entradas anteriores en la tabla se manejar\u00e1n correctamente. La ABI arm64 requiere que los campos de estructura de hasta 8 bytes est\u00e9n alineados de forma natural, con relleno agregado dentro de una estructura de modo que la estructura est\u00e9 adecuadamente alineada dentro de las matrices. Cuando CONFIG_DEBUG_BUGVERPOSE=y, el dise\u00f1o de una entrada de error es: struct bug_entry { firmado int bug_addr_disp; // 4 bytes firmados int file_disp; // L\u00ednea corta sin firmar de 4 bytes; // 2 bytes de banderas cortas sin firmar; // 2 bytes } ... con 12 bytes en total, que requieren una alineaci\u00f3n de 4 bytes. Cuando CONFIG_DEBUG_BUGVERBOSE=n, el dise\u00f1o de una entrada de error es: struct bug_entry { firmado int bug_addr_disp; // 4 bytes de banderas cortas sin firmar; // 2 bytes &lt; relleno impl\u00edcito &gt; // 2 bytes } ... con 8 bytes en total, con 6 bytes de datos y 2 bytes de relleno final, que requieren un alineamiento de 4 bytes. Cuando creamos un bug_entry en el ensamblado, alineamos el inicio de la entrada a 4 bytes, lo que impl\u00edcitamente maneja el relleno de cualquier entrada anterior. Sin embargo, no alineamos el final de la entrada, por lo que cuando CONFIG_DEBUG_BUGVERBOSE=n, la entrada final carece de los bytes de relleno finales. Para la imagen principal del kernel, esto no es un problema ya que find_bug() no depende de los bytes de relleno finales cuando se buscan entradas: for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug )) error de devoluci\u00f3n; Sin embargo, para los m\u00f3dulos, module_bug_finalize() depende de los bytes finales al calcular el n\u00famero de entradas: mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... y como la \u00faltima entrada_error carece de los bytes de relleno necesarios, esta entrada no se contar\u00e1, p.e. en el caso de una sola entrada: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; En consecuencia, module_find_bug() perder\u00e1 la \u00faltima entrada de error cuando lo haga: for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... lo que puede provocar p\u00e1nico en el kenrel debido a un error no controlado. Esto se puede demostrar con el siguiente m\u00f3dulo: static int __init buginit(void) { WARN(1, \"hello\\n\"); devolver 0; } vac\u00edo est\u00e1tico __exit bugexit(void) { } module_init(buginit); module_exit(salida de error); MODULE_LICENSE(\"GPL\"); ... lo que provocar\u00e1 un p\u00e1nico en el kernel cuando se cargue: ------------[ cortar aqu\u00ed ]------------ hola Excepci\u00f3n inesperada de BRK en el kernel en EL1 Error interno: Controlador BRK: 00000000f2000800 [#1] PREEMPT M\u00f3dulos SMP vinculados en: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Nombre de hardware: linux,dummy-virt (DT) pstate: 60400005 ( nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc:  ---truncado---"
    }
  ],
  "metrics": {},
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/22469a0335a1a1a690349b58bcb55822457df81e",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/3fd487ffaa697ddb05af78a75aaaddabe71c52b0",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/461a760d578b2b2c2faac3040b6b7c77baf128f8",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/9f2ad88f9b349554f64e4037ec185c84d7dd9c7d",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/c1929c041a262a4a27265db8dce3619c92aa678c",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/c27a2f7668e215c1ebbccd96fab27a220a93f1f7",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/f221bd58db0f6ca087ac0392284f6bce21f4f8ea",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ]
}