cve-2024-37354
Vulnerability from cvelistv5
Published
2024-06-25 14:22
Modified
2024-12-19 09:03
Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix crash on racing fsync and size-extending write into prealloc
We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():
BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
------------[ cut here ]------------
kernel BUG at fs/btrfs/ctree.c:2620!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
With the following stack trace:
#0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
#1 btrfs_drop_extents (fs/btrfs/file.c:411:4)
#2 log_one_extent (fs/btrfs/tree-log.c:4732:9)
#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
#7 btrfs_sync_file (fs/btrfs/file.c:1933:8)
#8 vfs_fsync_range (fs/sync.c:188:9)
#9 vfs_fsync (fs/sync.c:202:9)
#10 do_fsync (fs/sync.c:212:9)
#11 __do_sys_fdatasync (fs/sync.c:225:9)
#12 __se_sys_fdatasync (fs/sync.c:223:1)
#13 __x64_sys_fdatasync (fs/sync.c:223:1)
#14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
#15 do_syscall_64 (arch/x86/entry/common.c:83:7)
#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
So we're logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().
This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:
>>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
leaf 33439744 flags 0x100000000000000
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 7 transid 9 size 8192 nbytes 8473563889606862198
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
sequence 204 flags 0x10(PREALLOC)
atime 1716417703.220000000 (2024-05-22 15:41:43)
ctime 1716417704.983333333 (2024-05-22 15:41:44)
mtime 1716417704.983333333 (2024-05-22 15:41:44)
otime 17592186044416.000000000 (559444-03-08 01:40:16)
item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
index 195 namelen 3 name: 193
item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
location key (0 UNKNOWN.0 0) type XATTR
transid 7 data_len 1 name_len 6
name: user.a
data a
item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 303144960 nr 12288
extent data offset 0 nr 4096 ram 12288
extent compression 0 (none)
item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 4096 nr 8192
item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 8192 nr 4096
...
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.
Here is the state of
---truncated---
References
Impacted products
{ "containers": { "adp": [ { "metrics": [ { "other": { "content": { "id": "CVE-2024-37354", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "role": "CISA Coordinator", "timestamp": "2024-06-25T15:43:24.537360Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2024-06-25T15:43:32.621Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" }, { "providerMetadata": { "dateUpdated": "2024-08-02T03:50:56.095Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "defaultStatus": "unaffected", "product": "Linux", "programFiles": [ "fs/btrfs/tree-log.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "lessThan": "1ff2bd566fbcefcb892be85c493bdb92b911c428", "status": "affected", "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "versionType": "git" }, { "lessThan": "3d08c52ba1887a1ff9c179d4b6a18b427bcb2097", "status": "affected", "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "versionType": "git" }, { "lessThan": "f4e5ed974876c14d3623e04dc43d3e3281bc6011", "status": "affected", "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "versionType": "git" }, { "lessThan": "9d274c19a71b3a276949933859610721a453946b", "status": "affected", "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "versionType": "git" } ] }, { "defaultStatus": "affected", "product": "Linux", "programFiles": [ "fs/btrfs/tree-log.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "lessThanOrEqual": "6.1.*", "status": "unaffected", "version": "6.1.94", "versionType": "semver" }, { "lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.34", "versionType": "semver" }, { "lessThanOrEqual": "6.9.*", "status": "unaffected", "version": "6.9.5", "versionType": "semver" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "6.10", "versionType": "original_commit_for_fix" } ] } ], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\n\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\n\n BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/ctree.c:2620!\n invalid opcode: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\n\nWith the following stack trace:\n\n #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n #1 btrfs_drop_extents (fs/btrfs/file.c:411:4)\n #2 log_one_extent (fs/btrfs/tree-log.c:4732:9)\n #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n #7 btrfs_sync_file (fs/btrfs/file.c:1933:8)\n #8 vfs_fsync_range (fs/sync.c:188:9)\n #9 vfs_fsync (fs/sync.c:202:9)\n #10 do_fsync (fs/sync.c:212:9)\n #11 __do_sys_fdatasync (fs/sync.c:225:9)\n #12 __se_sys_fdatasync (fs/sync.c:223:1)\n #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\n\nSo we\u0027re logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\n\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\n\n \u003e\u003e\u003e print_extent_buffer(prog.crashed_thread().stack_trace()[0][\"eb\"])\n leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n leaf 33439744 flags 0x100000000000000\n fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n generation 7 transid 9 size 8192 nbytes 8473563889606862198\n block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n sequence 204 flags 0x10(PREALLOC)\n atime 1716417703.220000000 (2024-05-22 15:41:43)\n ctime 1716417704.983333333 (2024-05-22 15:41:44)\n mtime 1716417704.983333333 (2024-05-22 15:41:44)\n otime 17592186044416.000000000 (559444-03-08 01:40:16)\n item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n index 195 namelen 3 name: 193\n item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n location key (0 UNKNOWN.0 0) type XATTR\n transid 7 data_len 1 name_len 6\n name: user.a\n data a\n item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n generation 9 type 1 (regular)\n extent data disk byte 303144960 nr 12288\n extent data offset 0 nr 4096 ram 12288\n extent compression 0 (none)\n item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n generation 9 type 2 (prealloc)\n prealloc data disk byte 303144960 nr 12288\n prealloc data offset 4096 nr 8192\n item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n generation 9 type 2 (prealloc)\n prealloc data disk byte 303144960 nr 12288\n prealloc data offset 8192 nr 4096\n ...\n\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\n\nHere is the state of \n---truncated---" } ], "providerMetadata": { "dateUpdated": "2024-12-19T09:03:50.911Z", "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux" }, "references": [ { "url": "https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428" }, { "url": "https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097" }, { "url": "https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011" }, { "url": "https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b" } ], "title": "btrfs: fix crash on racing fsync and size-extending write into prealloc", "x_generator": { "engine": "bippy-5f407fcff5a0" } } }, "cveMetadata": { "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "assignerShortName": "Linux", "cveId": "CVE-2024-37354", "datePublished": "2024-06-25T14:22:36.228Z", "dateReserved": "2024-06-24T13:53:25.569Z", "dateUpdated": "2024-12-19T09:03:50.911Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1", "meta": { "nvd": "{\"cve\":{\"id\":\"CVE-2024-37354\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-06-25T15:15:13.177\",\"lastModified\":\"2024-11-21T09:23:42.537\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\\n\\nWe have been seeing crashes on duplicate keys in\\nbtrfs_set_item_key_safe():\\n\\n BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\\n ------------[ cut here ]------------\\n kernel BUG at fs/btrfs/ctree.c:2620!\\n invalid opcode: 0000 [#1] PREEMPT SMP PTI\\n CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\\n RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\\n\\nWith the following stack trace:\\n\\n #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\\n #1 btrfs_drop_extents (fs/btrfs/file.c:411:4)\\n #2 log_one_extent (fs/btrfs/tree-log.c:4732:9)\\n #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\\n #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\\n #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\\n #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\\n #7 btrfs_sync_file (fs/btrfs/file.c:1933:8)\\n #8 vfs_fsync_range (fs/sync.c:188:9)\\n #9 vfs_fsync (fs/sync.c:202:9)\\n #10 do_fsync (fs/sync.c:212:9)\\n #11 __do_sys_fdatasync (fs/sync.c:225:9)\\n #12 __se_sys_fdatasync (fs/sync.c:223:1)\\n #13 __x64_sys_fdatasync (fs/sync.c:223:1)\\n #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\\n #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\\n #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\\n\\nSo we\u0027re logging a changed extent from fsync, which is splitting an\\nextent in the log tree. But this split part already exists in the tree,\\ntriggering the BUG().\\n\\nThis is the state of the log tree at the time of the crash, dumped with\\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\\nto get more details than btrfs_print_leaf() gives us:\\n\\n \u003e\u003e\u003e print_extent_buffer(prog.crashed_thread().stack_trace()[0][\\\"eb\\\"])\\n leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\\n leaf 33439744 flags 0x100000000000000\\n fs uuid e5bd3946-400c-4223-8923-190ef1f18677\\n chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\\n item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\\n generation 7 transid 9 size 8192 nbytes 8473563889606862198\\n block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\\n sequence 204 flags 0x10(PREALLOC)\\n atime 1716417703.220000000 (2024-05-22 15:41:43)\\n ctime 1716417704.983333333 (2024-05-22 15:41:44)\\n mtime 1716417704.983333333 (2024-05-22 15:41:44)\\n otime 17592186044416.000000000 (559444-03-08 01:40:16)\\n item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\\n index 195 namelen 3 name: 193\\n item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\\n location key (0 UNKNOWN.0 0) type XATTR\\n transid 7 data_len 1 name_len 6\\n name: user.a\\n data a\\n item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\\n generation 9 type 1 (regular)\\n extent data disk byte 303144960 nr 12288\\n extent data offset 0 nr 4096 ram 12288\\n extent compression 0 (none)\\n item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\\n generation 9 type 2 (prealloc)\\n prealloc data disk byte 303144960 nr 12288\\n prealloc data offset 4096 nr 8192\\n item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\\n generation 9 type 2 (prealloc)\\n prealloc data disk byte 303144960 nr 12288\\n prealloc data offset 8192 nr 4096\\n ...\\n\\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\\nitem 5 starts at i_size.\\n\\nHere is the state of \\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el fallo en fsync de ejecuci\u00f3ns y escritura de extensi\u00f3n de tama\u00f1o en prealloc. Hemos estado viendo fallos en claves duplicadas en btrfs_set_item_key_safe(): BTRFS cr\u00edtico (dispositivo vdb): clave de ranura 4 ( 450 108 8192) nueva clave (450 108 8192) ------------[ cortar aqu\u00ed ]------------ ERROR del kernel en fs/btrfs/ctree.c: 2620! c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: cargado No contaminado 6.9.0 #6 Nombre de hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2 .fc40 01/04/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] Con el siguiente seguimiento de pila: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file .c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs /tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c :212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 Entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S :121) As\u00ed que estamos registrando una extensi\u00f3n modificada desde fsync, que es dividir una extensi\u00f3n en el \u00e1rbol de registro. Pero esta parte dividida ya existe en el \u00e1rbol, lo que activa el ERROR(). Este es el estado del \u00e1rbol de registro en el momento del bloqueo, descargado con drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) para obtener m\u00e1s detalles de los que proporciona btrfs_print_leaf() nosotros: \u0026gt;\u0026gt;\u0026gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][\\\"eb\\\"]) hoja 33439744 elementos de nivel 0 72 generaci\u00f3n 9 propietario 18446744073709551610 hoja 33439744 banderas 0x100000000000000 fs uuid 00c-4223-8923-190ef1f18677 fragmento uuid d58cb17e-6d02-494a-829a-18b7d8a399da clave del elemento 0 (450 INODE_ITEM 0) itemoff 16123 tama\u00f1o del elemento 160 generaci\u00f3n 7 transid 9 tama\u00f1o 8192 nbytes 8473563889606862198 grupo de bloques 0 modo 100600 enlaces 1 uid 0 gid 0 rdev 0 secuencia 204 banderas 0x10(PREALLOC ) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-2) 2 15:41:44) otime 17592186044416.000000000 (559444-03- 08 01:40:16) clave del elemento 1 (450 INODE_REF 256) itemoff 16110 tama\u00f1o del elemento 13 \u00edndice 195 namelen 3 nombre: 193 clave del elemento 2 (450 XATTR_ITEM 1640047104) itemoff 16073 tama\u00f1o del elemento 37 clave de ubicaci\u00f3n (0 UNKNOWN.0 0) tipo XATTR transid 7 data_len 1 name_len 6 nombre: usuario.a datos a elemento 3 clave (450 EXTENT_DATA 0) itemoff 16020 tama\u00f1o de elemento 53 generaci\u00f3n 9 tipo 1 (normal) byte de disco de datos de extensi\u00f3n 303144960 nr 12288 desplazamiento de datos de extensi\u00f3n 0 nr 4096 ram 12288 compresi\u00f3n de extensi\u00f3n 0 ( ninguno) clave del elemento 4 (450 EXTENT_DATA 4096) itemoff 15967 tama\u00f1o del elemento 53 generaci\u00f3n 9 tipo 2 (preasignaci\u00f3n) byte de disco de datos de preasignaci\u00f3n 303144960 nr 12288 compensaci\u00f3n de datos de preasignaci\u00f3n 4096 nr 8192 clave del elemento 5 (450 EXTENT_DATA 8192) itemoff 15914 tama\u00f1o del elemento 53 generaci\u00f3n 9 tipo 2 (preasignaci\u00f3n) byte de disco de datos de preasignaci\u00f3n 303144960 nr 12288 desplazamiento de datos de preasignaci\u00f3n 8192 nr 4096 ... Entonces, el verdadero problema ocurri\u00f3 antes: observe que los elementos 4 (4k-12k) y 5 (8k-12k) se superponen. Ambas son extensiones de preasignaci\u00f3n. El elemento 4 abarca i_size y el elemento 5 comienza en i_size. Aqu\u00ed est\u00e1 el estado de ---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}" } }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.