Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "f2fs: remove non-uptodate folio from the page cache in move_data_block"<br /> <br /> This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.<br /> <br /> The kernel panics are keeping to be reported especially when the f2fs<br /> partition get almost full. By investigation, we find that the reason is<br /> one f2fs page got freed to buddy without being deleted from LRU and the<br /> root cause is the race happened in [2] which is enrolled by this commit.<br /> <br /> There are 3 race processes in this scenario, please find below for their<br /> main activities.<br /> <br /> The changed code in move_data_block() lets the GC path evict the tail-end<br /> folio from the page cache through folio_end_dropbehind(). Once<br /> folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the<br /> page-cache references for all pages in the folio are dropped. The folio<br /> is then kept alive only by temporary external references, which allows a<br /> later split to operate on a folio whose subpages are no longer protected<br /> by page-cache references.<br /> <br /> After the page-cache references are gone, split_folio_to_order() can<br /> split the big folio into individual pages and put the resulting subpages<br /> back on the LRU. For tail pages beyond EOF, split removes them from the<br /> page cache and drops their page-cache references. A tail page can then<br /> remain on the LRU with PG_lru set while holding only the split caller&amp;#39;s<br /> temporary reference. When free_folio_and_swap_cache() drops that final<br /> reference, the page enters the final folio_put() release path.<br /> <br /> In parallel, folio_isolate_lru() can observe the same tail page with a<br /> non-zero refcount and PG_lru set. It clears PG_lru before taking its own<br /> reference. If this races with the final folio_put() from the split path,<br /> __folio_put() sees PG_lru already cleared and skips lruvec_del_folio().<br /> The page is then freed back to the allocator while its lru links are<br /> still present in the LRU list. A later LRU operation on a neighboring<br /> page detects the stale link and reports list corruption.<br /> <br /> [1]<br /> [ 22.486082] list_del corruption. next-&gt;prev should be fffffffec10e0ac8, but was dead000000000122. (next=fffffffec10e0a88)<br /> [ 22.486130] ------------[ cut here ]------------<br /> [ 22.486134] kernel BUG at lib/list_debug.c:67!<br /> [ 22.486141] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 22.488502] Tainted: [W]=WARN, [O]=OOT_MODULE<br /> [ 22.488506] Hardware name: Spreadtrum UMS9230 1H10 SoC (DT)<br /> [ 22.488511] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.488517] pc : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488531] lr : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488539] sp : ffffffc08006b830<br /> [ 22.488542] x29: ffffffc08006b868 x28: 0000000000003020 x27: 0000000000000000<br /> [ 22.488553] x26: 0000000000000000 x25: 0000000000000004 x24: fffffffec10e0ac0<br /> [ 22.488564] x23: 00000000000000e8 x22: 0000000000000024 x21: dead000000000122<br /> [ 22.488574] x20: fffffffec10e0a88 x19: fffffffec10e0ac8 x18: ffffffc080061060<br /> [ 22.488585] x17: 20747562202c3863 x16: 6130653031636566 x15: 0000000000000058<br /> [ 22.488595] x14: 0000000000000004 x13: ffffff80f91e0000 x12: 0000000000000003<br /> [ 22.488605] x11: 0000000000000003 x10: 0000000000000001 x9 : ffe85721f0e25f00<br /> [ 22.488615] x8 : ffe85721f0e25f00 x7 : 0000000000000000 x6 : 6c65645f7473696c<br /> [ 22.488625] x5 : ffffffed39b23026 x4 : 0000000000000000 x3 : 0000000000000010<br /> [ 22.488636] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000006d<br /> [ 22.488647] Call trace:<br /> [ 22.488651] __list_del_entry_valid_or_report+0x14c/0x154 (P)<br /> [ 22.488661] __folio_put+0x2bc/0x434<br /> [ 22.488670] folio_put+0x28/0x58<br /> [ 22.488678] do_garbage_collect+0x1a34/0x2584<br /> [ 22.488689] f2fs_gc+0x230/0x9b4<br /> [ 22.488697] f2fs_fallocate+0xb90/0xdf4<br /> [ 22.488706] vfs_fallocate+0x1b4/0x2bc<br /> [ 22.488716] __arm64_sys_fallocate+0x44/0x78<br /> [ 22.488725] invoke_syscall+0x58/0xe4<br /> [ 22.488732] do_el0_svc+0x48/0xdc<br /> [ 22.488739] el0<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate ACL entry sizes in f2fs_acl_from_disk()<br /> <br /> f2fs_acl_count() only validates the aggregate ACL xattr length. A<br /> malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only<br /> contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk()<br /> then reads entry-&gt;e_id before verifying that a full entry fits.<br /> <br /> Require a short entry before reading e_tag and e_perm, and require a<br /> full entry before reading e_id for ACL_USER and ACL_GROUP. Return<br /> -EFSCORRUPTED from these new truncated-entry checks, while keeping the<br /> pre-existing -EINVAL paths unchanged.<br /> <br /> Validation reproduced this kernel report:<br /> KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0<br /> RIP: 0033:0x7f4b835ea7aa<br /> The buggy address belongs to the object at ffff888114589960 which belongs<br /> to the cache kmalloc-8 of size 8<br /> The buggy address is located 0 bytes to the right of allocated 8-byte<br /> region [ffff888114589960, ffff888114589968)<br /> Read of size 4<br /> Call trace:<br /> dump_stack_lvl+0x66/0xa0 (?:?)<br /> print_report+0xce/0x630 (?:?)<br /> __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> __virt_addr_valid+0x224/0x430 (?:?)<br /> kasan_report+0xe0/0x110 (?:?)<br /> __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169)<br /> __get_acl+0x281/0x380 (?:?)<br /> vfs_get_acl+0x10b/0x190 (?:?)<br /> do_get_acl+0x2a/0x410 (?:?)<br /> do_get_acl+0x9/0x410 (?:?)<br /> do_getxattr+0xe8/0x260 (?:?)<br /> filename_getxattr+0xd1/0x140 (?:?)<br /> do_getname+0x2d/0x2d0 (?:?)<br /> path_getxattrat+0x16c/0x200 (?:?)<br /> lock_release+0xc8/0x290 (?:?)<br /> cgroup_update_frozen+0x9d/0x320 (?:?)<br /> lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?)<br /> trace_hardirqs_on+0x1a/0x170 (?:?)<br /> _raw_spin_unlock_irq+0x28/0x50 (?:?)<br /> do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: bound i_inline_xattr_size for non-inline-xattr inodes<br /> <br /> When the flexible_inline_xattr feature is enabled, do_read_inode() loads<br /> the on-disk i_inline_xattr_size unconditionally:<br /> <br /> if (f2fs_sb_has_flexible_inline_xattr(sbi))<br /> fi-&gt;i_inline_xattr_size = le16_to_cpu(ri-&gt;i_inline_xattr_size);<br /> <br /> but sanity_check_inode() only range-checks it when the inode also has the<br /> FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline<br /> data but not FI_INLINE_XATTR -- the normal layout for an inline<br /> directory -- therefore keeps a fully attacker-controlled<br /> i_inline_xattr_size from a crafted image.<br /> <br /> get_inline_xattr_addrs() returns that value with no flag gating, so it<br /> feeds the inode geometry:<br /> <br /> MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)<br /> NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)<br /> addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size<br /> <br /> A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY()<br /> negative, so make_dentry_ptr_inline() sets d-&gt;max (int) to a negative<br /> value. The inline directory walk then compares an unsigned long bit_pos<br /> against that negative d-&gt;max, which is promoted to a huge unsigned bound,<br /> and reads far past the inline area:<br /> <br /> while (bit_pos max) /* fs/f2fs/dir.c */<br /> ... test_bit_le(bit_pos, d-&gt;bitmap) / d-&gt;dentry[bit_pos] ...<br /> <br /> Mounting a crafted image and reading such a directory triggers an<br /> out-of-bounds read in f2fs_fill_dentries(); the same underflow also<br /> corrupts ADDRS_PER_INODE for regular files.<br /> <br /> Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the<br /> flexible_inline_xattr feature is enabled -- i.e. whenever the value is<br /> loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE<br /> bound gated on inodes that actually carry an inline xattr, so legitimate<br /> inodes with i_inline_xattr_size == 0 are still accepted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode<br /> <br /> - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE) - shrink<br /> - f2fs_gc<br /> - gc_data_segment<br /> - ra_data_block(cow_inode)<br /> - mapping = F2FS_I(inode)-&gt;atomic_inode-&gt;i_mapping<br /> : f2fs_is_cow_file(cow_inode) is true<br /> - f2fs_evict_inode(atomic_inode)<br /> - clear_inode_flag(fi-&gt;cow_inode, FI_COW_FILE)<br /> - F2FS_I(fi-&gt;cow_inode)-&gt;atomic_inode = NULL<br /> ...<br /> - truncate_inode_pages_final(atomic_inode)<br /> - f2fs_grab_cache_folio(mapping)<br /> : create folio in atomic_inode-&gt;mapping<br /> - clear_inode(atomic_inode)<br /> - BUG_ON(atomic_inode-&gt;i_data.nrpages)<br /> <br /> We need to add a reference on fi-&gt;atomic_inode before using its mapping<br /> field during garbage collection, otherwise, it will cause UAF issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate compress cache inode only when enabled<br /> <br /> F2FS_COMPRESS_INO() uses NM_I(sbi)-&gt;max_nid as the synthetic inode<br /> number for the compressed page cache inode. That inode only exists when<br /> the compress_cache mount option is enabled.<br /> <br /> When compress_cache is disabled, max_nid is outside the valid inode<br /> range. A corrupted directory entry that points to ino == max_nid should<br /> therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino()<br /> currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally,<br /> so f2fs_iget() bypasses do_read_inode() and its nid range check, and<br /> instantiates a fake internal inode instead.<br /> <br /> Gate the compressed cache inode case on COMPRESS_CACHE, matching<br /> f2fs_init_compress_inode(). With compress_cache disabled, ino ==<br /> max_nid now follows the normal inode path and is rejected as an<br /> out-of-range nid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate orphan inode entry count<br /> <br /> f2fs_recover_orphan_inodes() trusts the orphan block entry_count when<br /> replaying orphan inodes from the checkpoint pack. A corrupted entry_count<br /> larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the<br /> ino[] array and interpret footer or following data as inode numbers.<br /> <br /> On a crafted image, mounting an unpatched kernel can drive orphan recovery<br /> into f2fs_bug_on() and panic the kernel. Validate entry_count before<br /> consuming entries so corrupted checkpoint data fails the mount with<br /> -EFSCORRUPTED and requests fsck instead.<br /> <br /> Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be<br /> recorded in the superblock s_errors[] field. This gives fsck a persistent<br /> hint even though mount-time orphan recovery failure may leave no chance to<br /> persist SBI_NEED_FSCK through a checkpoint.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on f2fs_get_node_folio_ra()<br /> <br /> kernel BUG at fs/f2fs/file.c:845!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c:845<br /> Code: fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1 fc fc 90 0f 0b e8 6c 9d 9a fd 90 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90<br /> RSP: 0018:ffffc9000e4474c0 EFLAGS: 00010283<br /> RAX: ffffffff842b1d34 RBX: 0000000000000003 RCX: 0000000000100000<br /> RDX: ffffc9000f03a000 RSI: 0000000000035503 RDI: 0000000000035504<br /> RBP: ffffc9000e447608 R08: ffff8880123b0000 R09: 0000000000000002<br /> R10: 00000000fffffffe R11: 0000000000000002 R12: 0000000000000001<br /> R13: 0000000000000000 R14: 1ffff92001c88ea0 R15: 00000000ffff039c<br /> FS: 00007f7e02ee36c0(0000) GS:ffff88808c887000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff0305c4000 CR3: 0000000012d4c000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:882<br /> f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c:940<br /> f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode.c:907<br /> evict+0x61e/0xb10 fs/inode.c:841<br /> f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c:5224<br /> get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694<br /> vfs_get_tree+0x92/0x2a0 fs/super.c:1754<br /> fc_mount fs/namespace.c:1193 [inline]<br /> do_new_mount_fc fs/namespace.c:3758 [inline]<br /> do_new_mount+0x341/0xd30 fs/namespace.c:3834<br /> do_mount fs/namespace.c:4167 [inline]<br /> __do_sys_mount fs/namespace.c:4383 [inline]<br /> __se_sys_mount+0x31d/0x420 fs/namespace.c:4360<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> count = ADDRS_PER_PAGE(dn.node_folio, inode);<br /> <br /> count -= dn.ofs_in_node;<br /> f2fs_bug_on(sbi, count check whether it is inode|xnode

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: fix use-after-free in gfs2_qd_dealloc<br /> <br /> gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(),<br /> accesses the superblock object sdp through qd-&gt;qd_sbd after freeing qd.<br /> It does so to decrement sd_quota_count and wake up sd_kill_wait.<br /> <br /> However, by the time the RCU callback runs, gfs2_put_super() may have<br /> already freed sdp via free_sbd(). This can happen when<br /> gfs2_quota_cleanup() is called during unmount: it disposes of quota<br /> objects via call_rcu() and then waits on sd_kill_wait with a 60-second<br /> timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers<br /> additional qd_put() calls that schedule more RCU callbacks after the<br /> wait completes, gfs2_put_super() will proceed to free the superblock<br /> while RCU callbacks referencing it are still pending.<br /> <br /> Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure<br /> all pending RCU callbacks (including gfs2_qd_dealloc) have completed<br /> before the superblock is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Avoid mounting the bdev pseudo-filesystem in userspace<br /> <br /> The bdev pseudo-filesystem is an internal kernel filesystem with which<br /> userspace should not interfere. Unregister it so that userspace cannot<br /> even attempt to mount it.<br /> <br /> This fixes a bug [1] that occurs when attempting to access files,<br /> because the system call move_mount() uses pointers declared in the<br /> inode_operations structure, which for the bdev pseudo-filesystem<br /> are always equal to 0. `inode-&gt;i_op = &amp;empty_iops;`<br /> <br /> [1]<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> PGD 23380067 P4D 23380067 PUD 23381067 PMD 0<br /> Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:0x0<br /> <br /> Call Trace:<br /> <br /> lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460<br /> open_last_lookups fs/namei.c:3550 [inline]<br /> path_openat+0x953/0x2700 fs/namei.c:3780<br /> do_filp_open+0x1c5/0x410 fs/namei.c:3810<br /> do_sys_openat2+0x171/0x4d0 fs/open.c:1318<br /> do_sys_open fs/open.c:1334 [inline]<br /> __do_sys_openat fs/open.c:1350 [inline]<br /> __se_sys_openat fs/open.c:1345 [inline]<br /> __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: nx - fix nx_crypto_ctx_exit argument<br /> <br /> nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...)<br /> but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *.<br /> <br /> Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx<br /> call.<br /> <br /> This fixes the following oops:<br /> <br /> BUG: Unable to handle kernel data access at 0xc0403effffffffc8<br /> Faulting instruction address: 0xc000000000396cb4<br /> Oops: Kernel access of bad area, sig: 11 [#15]<br /> Call Trace:<br /> nx_crypto_ctx_shash_exit+0x24/0x60<br /> crypto_shash_exit_tfm+0x28/0x40<br /> crypto_destroy_tfm+0x98/0x140<br /> crypto_exit_ahash_using_shash+0x20/0x40<br /> crypto_destroy_tfm+0x98/0x140<br /> hash_release+0x1c/0x30<br /> alg_sock_destruct+0x38/0x60<br /> __sk_destruct+0x48/0x2b0<br /> af_alg_release+0x58/0xb0<br /> __sock_release+0x68/0x150<br /> sock_close+0x20/0x40<br /> __fput+0x110/0x3a0<br /> sys_close+0x48/0xa0<br /> system_call_exception+0x140/0x2d0<br /> system_call_common+0xf4/0x258<br /> <br /> .. which came from hardlink(1) opportunistically using AF_ALG.<br /> <br /> The same problem exists with nx_crypto_ctx_skcipher_exit getting a context<br /> it wasn&amp;#39;t expecting, but apparently nobody hit that for years.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned()<br /> <br /> Drop a BUG_ON() that has been reachable since it was first added, way back<br /> in 2009, and instead use get_unaligned() to perform potentially-unaligned<br /> accesses.<br /> <br /> For a given store, KVM x86&amp;#39;s emulator tracks the entire value in the<br /> destination operand, x86_emulate_ctxt.dst. If the destination is memory,<br /> and the target splits multiple pages and/or is emulated MMIO, then KVM<br /> handles each fragment independently. E.g. on a page split starting at page<br /> offset 0xffc, KVM writes 4 bytes to the first page, then the remaining<br /> bytes to the second page, using ctxt-&gt;dst as the source for both (with<br /> appropriate offsets).<br /> <br /> If the destination splits a page *and* hits emulated MMIO on the second<br /> page, then KVM will complete the write to the first page, then emulate the<br /> MMIO access to the second page. If there is a datamatch-enabled ioeventfd<br /> at offset 0 of the second page, then KVM will process the remainder of the<br /> store as a potential ioeventfd signal.<br /> <br /> Putting it all together, if the guest emits a store that splits a page<br /> starting at page offset N, and the second page has a datamatch-enabled<br /> ioeventfd at offset 0, then KVM will check for datamatch using<br /> &amp;dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being<br /> 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires.<br /> <br /> E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8,<br /> all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON()<br /> fires due to @val being 4-byte aligned, but not 8-byte aligned.<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783!<br /> Oops: invalid opcode: 0000 [#1] SMP<br /> CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm]<br /> Call Trace:<br /> <br /> __kvm_io_bus_write+0x85/0xb0 [kvm]<br /> kvm_io_bus_write+0x53/0x80 [kvm]<br /> vcpu_mmio_write+0x66/0xf0 [kvm]<br /> emulator_read_write_onepage+0x12a/0x540 [kvm]<br /> emulator_read_write+0x109/0x2b0 [kvm]<br /> x86_emulate_insn+0x4f8/0xfb0 [kvm]<br /> x86_emulate_instruction+0x181/0x790 [kvm]<br /> kvm_mmu_page_fault+0x313/0x630 [kvm]<br /> vmx_handle_exit+0x18a/0x590 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm]<br /> kvm_vcpu_ioctl+0x2d5/0x970 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb7/0x890<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f19c931a9bf<br /> <br /> Modules linked in: kvm_intel kvm irqbypass<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM<br /> x86 doesn&amp;#39;t perform alignment checks on "normal" memory accesses at CPL0.<br /> Sadly, C99 ruins all the fun; while the x86 architecture plays nice,<br /> dereferencing an unaligned pointer directly is undefined behavior in C,<br /> e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level<br /> <br /> When recovering hugepages in the shadow MMU, verify that the base gfn of<br /> the shadow page is actually contained within the target memslot, *before*<br /> querying the max mapping level given the shadow page&amp;#39;s gfn. Failure to<br /> pre-check the validity of the gfn can lead to an out-of-bounds access to<br /> the slot&amp;#39;s lpage_info (which typically manifests as a host #PF because the<br /> lpage_info is vmalloc&amp;#39;d) if the guest creates a hugepage mapping (in its<br /> PTEs) that extends "below" the bounds of a memslot.<br /> <br /> When faulting in memory for a guest, and the size of the guest mapping is<br /> greater than KVM&amp;#39;s (current) max mapping, then KVM will create a "direct"<br /> shadow page (direct in that there are no gPTEs to shadow, and so the target<br /> gfn is a direct calculation given the base gfn of the shadow page). The<br /> hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB<br /> mappings when dirty logging generates the guest &gt; host mapping size case.<br /> When the 4KiB restriction is lifted, then KVM can replace the shadow page<br /> with a hugepage.<br /> <br /> But if KVM originally used a smaller mapping than the guest because the<br /> range of memory covered by the guest hugepage exceeds the bounds of a<br /> memslot, then KVM will link a direct shadow page with a gfn that is outside<br /> the bounds of the memslot being used to fault in memory. The rmap entry<br /> added for the leaf mapping is correct and within bounds, but the gfn of the<br /> leaf SPTE&amp;#39;s parent shadow page will be out of bounds.<br /> <br /> BUG: unable to handle page fault for address: ffffc90000806ffc<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]<br /> Call Trace:<br /> <br /> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]<br /> kvm_set_memslot+0x1ee/0x590 [kvm]<br /> kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]<br /> kvm_vm_ioctl+0x9bf/0x15d0 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb7/0xbb0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f21c0f1a9bf<br /> <br /> <br /> Don&amp;#39;t bother pre-checking the bounds of the potential hugepage, i.e. don&amp;#39;t<br /> check that e.g. sp-&gt;gfn + KVM_PAGES_PER_HPAGE(sp-&gt;role.level + 1) is also<br /> within the memslot, as the checks performed by kvm_mmu_max_mapping_level()<br /> are a superset of the basic bounds checks. I.e. pre-checking the full<br /> range would be a dubious micro-optimization.