mirror of
https://github.com/fkie-cad/nvd-json-data-feeds.git
synced 2025-05-28 09:11:28 +00:00
33 lines
3.6 KiB
JSON
33 lines
3.6 KiB
JSON
{
|
|
"id": "CVE-2024-26972",
|
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
|
"published": "2024-05-01T06:15:13.597",
|
|
"lastModified": "2024-10-10T12:15:03.297",
|
|
"vulnStatus": "Awaiting Analysis",
|
|
"cveTags": [],
|
|
"descriptions": [
|
|
{
|
|
"lang": "en",
|
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: ubifs_symlink: Fix memleak of inode->i_link in error path\n\nFor error handling path in ubifs_symlink(), inode will be marked as\nbad first, then iput() is invoked. If inode->i_link is initialized by\nfscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't\nbe freed by callchain ubifs_free_inode -> fscrypt_free_inode in error\nhandling path, because make_bad_inode() has changed 'inode->i_mode' as\n'S_IFREG'.\nFollowing kmemleak is easy to be reproduced by injecting error in\nubifs_jnl_update() when doing symlink in encryption scenario:\n unreferenced object 0xffff888103da3d98 (size 8):\n comm \"ln\", pid 1692, jiffies 4294914701 (age 12.045s)\n backtrace:\n kmemdup+0x32/0x70\n __fscrypt_encrypt_symlink+0xed/0x1c0\n ubifs_symlink+0x210/0x300 [ubifs]\n vfs_symlink+0x216/0x360\n do_symlinkat+0x11a/0x190\n do_syscall_64+0x3b/0xe0\nThere are two ways fixing it:\n 1. Remove make_bad_inode() in error handling path. We can do that\n because ubifs_evict_inode() will do same processes for good\n symlink inode and bad symlink inode, for inode->i_nlink checking\n is before is_bad_inode().\n 2. Free inode->i_link before marking inode bad.\nMethod 2 is picked, it has less influence, personally, I think."
|
|
},
|
|
{
|
|
"lang": "es",
|
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: ubifs_symlink: corrige la fuga de memleak de inodo->i_link en la ruta de error Para el manejo de errores en la ruta en ubifs_symlink(), el inodo se marcar\u00e1 como incorrecto primero y luego se invocar\u00e1 iput(). Si inode->i_link se inicializa mediante fscrypt_encrypt_symlink() en el escenario de cifrado, inode->i_link no ser\u00e1 liberado por la cadena de llamadas ubifs_free_inode -> fscrypt_free_inode en la ruta de manejo de errores, porque make_bad_inode() ha cambiado 'inode->i_mode' como 'S_IFREG '. El siguiente kmemleak es f\u00e1cil de reproducir inyectando un error en ubifs_jnl_update() al realizar un enlace simb\u00f3lico en un escenario de cifrado: objeto sin referencia 0xffff888103da3d98 (tama\u00f1o 8): comm \"ln\", pid 1692, jiffies 4294914701 (edad 12.045 s) backtrace: kmemdup+0x32/ 0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 Hay dos formas de solucionarlo: 1. Eliminar make_bad _inode() en la ruta de manejo de errores. Podemos hacer eso porque ubifs_evict_inode() realizar\u00e1 los mismos procesos para el inodo de enlace simb\u00f3lico bueno y el inodo de enlace simb\u00f3lico incorrecto, para inodo->i_nlink la verificaci\u00f3n es antes de is_bad_inode(). 2. Libere inodo->i_link antes de marcar el inodo como incorrecto. Se elige el m\u00e9todo 2, creo que tiene menos influencia, personalmente."
|
|
}
|
|
],
|
|
"metrics": {},
|
|
"references": [
|
|
{
|
|
"url": "https://git.kernel.org/stable/c/3faea7810e2b3e9a9a92ef42d7e5feaeb8ff7133",
|
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
|
},
|
|
{
|
|
"url": "https://git.kernel.org/stable/c/62b5ae00c2b835639002ce898ccb5d82c51073ae",
|
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
|
},
|
|
{
|
|
"url": "https://git.kernel.org/stable/c/6379b44cdcd67f5f5d986b73953e99700591edfa",
|
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
|
}
|
|
]
|
|
} |