CVE-2026-43118

{"id": "CVE-2026-43118", "cveTags": [], "metrics": {"cvssMetricV31": [{"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": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "126999610eddeb1de3b47680585f4bc9531dc7f4", "versionType": "git"}, {"status": "affected", "version": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "c939bfa67d221f75351a5bf2fc912e8125547b7e", "versionType": "git"}, {"status": "affected", "version": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "91990732ec4ce5c09361d498c6d621f5a76ee1f2", "versionType": "git"}, {"status": "affected", "version": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "fddb157536e67a055597f00a8b4922d5f5ed0826", "versionType": "git"}, {"status": "affected", "version": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "03e966b63df5b06790310c1faaf3e0cb43adea8b", "versionType": "git"}, {"status": "affected", "version": "12fcfd22fe5bf4fe74710232098bc101af497995", "lessThan": "5254d4181add9dfaa5e3519edd71cc8f752b2f85", "versionType": "git"}], "programFiles": ["fs/btrfs/tree-log.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "2.6.30"}, {"status": "unaffected", "version": "0", "lessThan": "2.6.30", "versionType": "semver"}, {"status": "unaffected", "version": "6.1.191", "versionType": "semver", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.6.160", "versionType": "semver", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.12.114", "versionType": "semver", "lessThanOrEqual": "6.12.*"}, {"status": "unaffected", "version": "6.18.24", "versionType": "semver", "lessThanOrEqual": "6.18.*"}, {"status": "unaffected", "version": "6.19.14", "versionType": "semver", "lessThanOrEqual": "6.19.*"}, {"status": "unaffected", "version": "7.0", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["fs/btrfs/tree-log.c"], "defaultStatus": "affected"}]}], "published": "2026-05-06T10:16:25.633", "references": [{"url": "https://git.kernel.org/stable/c/03e966b63df5b06790310c1faaf3e0cb43adea8b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/126999610eddeb1de3b47680585f4bc9531dc7f4", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/5254d4181add9dfaa5e3519edd71cc8f752b2f85", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/91990732ec4ce5c09361d498c6d621f5a76ee1f2", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c939bfa67d221f75351a5bf2fc912e8125547b7e", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/fddb157536e67a055597f00a8b4922d5f5ed0826", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix zero size inode with non-zero size after log replay\n\nWhen logging that an inode exists, as part of logging a new name or\nlogging new dir entries for a directory, we always set the generation of\nthe logged inode item to 0. This is to signal during log replay (in\noverwrite_item()), that we should not set the i_size since we only logged\nthat an inode exists, so the i_size of the inode in the subvolume tree\nmust be preserved (as when we log new names or that an inode exists, we\ndon't log extents).\n\nThis works fine except when we have already logged an inode in full mode\nor it's the first time we are logging an inode created in a past\ntransaction, that inode has a new i_size of 0 and then we log a new name\nfor the inode (due to a new hardlink or a rename), in which case we log\nan i_size of 0 for the inode and a generation of 0, which causes the log\nreplay code to not update the inode's i_size to 0 (in overwrite_item()).\n\nAn example scenario:\n\n mkdir /mnt/dir\n xfs_io -f -c \"pwrite 0 64K\" /mnt/dir/foo\n\n sync\n\n xfs_io -c \"truncate 0\" -c \"fsync\" /mnt/dir/foo\n\n ln /mnt/dir/foo /mnt/dir/bar\n\n xfs_io -c \"fsync\" /mnt/dir\n\n <power fail>\n\nAfter log replay the file remains with a size of 64K. This is because when\nwe first log the inode, when we fsync file foo, we log its current i_size\nof 0, and then when we create a hard link we log again the inode in exists\nmode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we\nadd to the log tree, so during log replay overwrite_item() sees that the\ngeneration is 0 and i_size is 0 so we skip updating the inode's i_size\nfrom 64K to 0.\n\nFix this by making sure at fill_inode_item() we always log the real\ngeneration of the inode if it was logged in the current transaction with\nthe i_size we logged before. Also if an inode created in a previous\ntransaction is logged in exists mode only, make sure we log the i_size\nstored in the inode item located from the commit root, so that if we log\nmultiple times that the inode exists we get the correct i_size.\n\nA test case for fstests will follow soon."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nbtrfs: corrige inode de tama\u00f1o cero con tama\u00f1o no cero despu\u00e9s de la reproducci\u00f3n del registro\n\nAl registrar que un inode existe, como parte de registrar un nuevo nombre o registrar nuevas entradas de directorio para un directorio, siempre establecemos la generaci\u00f3n del elemento inode registrado en 0. Esto es para se\u00f1alar durante la reproducci\u00f3n del registro (en overwrite_item()), que no debemos establecer el i_size ya que solo registramos que un inode existe, por lo que el i_size del inode en el \u00e1rbol del subvolumen debe preservarse (ya que cuando registramos nuevos nombres o que un inode existe, no registramos extensiones).\n\nEsto funciona bien excepto cuando ya hemos registrado un inode en modo completo o es la primera vez que registramos un inode creado en una transacci\u00f3n pasada, ese inode tiene un nuevo i_size de 0 y luego registramos un nuevo nombre para el inode (debido a un nuevo enlace duro o un cambio de nombre), en cuyo caso registramos un i_size de 0 para el inode y una generaci\u00f3n de 0, lo que hace que el c\u00f3digo de reproducci\u00f3n del registro no actualice el i_size del inode a 0 (en overwrite_item()).\n\nUn escenario de ejemplo:\n\n mkdir /mnt/dir\n xfs_io -f -c \u2019pwrite 0 64K\u2019 /mnt/dir/foo\n\n sync\n\n xfs_io -c \u2019truncate 0\u2019 -c \u2019fsync\u2019 /mnt/dir/foo\n\n ln /mnt/dir/foo /mnt/dir/bar\n\n xfs_io -c \u2019fsync\u2019 /mnt/dir\n\n <falla de energ\u00eda>\n\nDespu\u00e9s de la reproducci\u00f3n del registro, el archivo permanece con un tama\u00f1o de 64K. Esto se debe a que cuando registramos el inode por primera vez, al hacer fsync del archivo foo, registramos su i_size actual de 0, y luego, cuando creamos un enlace duro, volvemos a registrar el inode en modo de existencia (LOG_INODE_EXISTS) pero establecemos una generaci\u00f3n de 0 para el elemento inode que agregamos al \u00e1rbol de registro, por lo que durante la reproducci\u00f3n del registro overwrite_item() ve que la generaci\u00f3n es 0 y el i_size es 0, por lo que omitimos actualizar el i_size del inode de 64K a 0.\n\nEsto se corrige asegur\u00e1ndonos de que en fill_inode_item() siempre registramos la generaci\u00f3n real del inode si fue registrado en la transacci\u00f3n actual con el i_size que registramos antes. Adem\u00e1s, si un inode creado en una transacci\u00f3n anterior se registra solo en modo de existencia, nos aseguramos de registrar el i_size almacenado en el elemento inode ubicado desde la ra\u00edz de commit, de modo que si registramos varias veces que el inode existe, obtenemos el i_size correcto.\n\nPronto seguir\u00e1 un caso de prueba para fstests."}], "lastModified": "2026-11-11T21:10:00.200", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "7560884D-457B-4E3F-9047-894A786C1273", "versionEndExcluding": "6.18.24", "versionStartIncluding": "2.6.30"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D6A8A074-BBF4-4803-ABED-519A839435BB", "versionEndExcluding": "6.19.14", "versionStartIncluding": "6.19"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "58A9FEFF-C040-420D-8F0A-BFDAAA1DF258"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}