Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: Fix kmemleak in blk_mq_init_allocated_queue<br /> <br /> There is a kmemleak caused by modprobe null_blk.ko<br /> <br /> unreferenced object 0xffff8881acb1f000 (size 1024):<br /> comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S......<br /> backtrace:<br /> [] kmalloc_node_trace+0x22/0x60<br /> [] blk_mq_alloc_and_init_hctx+0x289/0x350<br /> [] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0<br /> [] blk_mq_init_allocated_queue+0x48c/0x1440<br /> [] __blk_mq_alloc_disk+0xc8/0x1c0<br /> [] 0xffffffffc450d69d<br /> [] 0xffffffffc4538392<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> That is because q-&gt;ma_ops is set to NULL before blk_release_queue is<br /> called.<br /> <br /> blk_mq_init_queue_data<br /> blk_mq_init_allocated_queue<br /> blk_mq_realloc_hw_ctxs<br /> for (i = 0; i nr_hw_queues; i++) {<br /> old_hctx = xa_load(&amp;q-&gt;hctx_table, i);<br /> if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1]<br /> if (!old_hctx)<br /> break;<br /> <br /> xa_for_each_start(&amp;q-&gt;hctx_table, j, hctx, j)<br /> blk_mq_exit_hctx(q, set, hctx, j); [2]<br /> <br /> if (!q-&gt;nr_hw_queues) [3]<br /> goto err_hctxs;<br /> <br /> err_exit:<br /> q-&gt;mq_ops = NULL; [4]<br /> <br /> blk_put_queue<br /> blk_release_queue<br /> if (queue_is_mq(q)) [5]<br /> blk_mq_release(q);<br /> <br /> [1]: blk_mq_alloc_and_init_hctx failed at i != 0.<br /> [2]: The hctxs allocated by [1] are moved to q-&gt;unused_hctx_list and<br /> will be cleaned up in blk_mq_release.<br /> [3]: q-&gt;nr_hw_queues is 0.<br /> [4]: Set q-&gt;mq_ops to NULL.<br /> [5]: queue_is_mq returns false due to [4]. And blk_mq_release<br /> will not be called. The hctxs in q-&gt;unused_hctx_list are leaked.<br /> <br /> To fix it, call blk_release_queue in exception path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix cxl_region leak, cleanup targets at region delete<br /> <br /> When a region is deleted any targets that have been previously assigned<br /> to that region hold references to it. Trigger those references to<br /> drop by detaching all targets at unregister_region() time.<br /> <br /> Otherwise that region object will leak as userspace has lost the ability<br /> to detach targets once region sysfs is torn down.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix tree mod log mishandling of reallocated nodes<br /> <br /> We have been seeing the following panic in production<br /> <br /> kernel BUG at fs/btrfs/tree-mod-log.c:677!<br /> invalid opcode: 0000 [#1] SMP<br /> RIP: 0010:tree_mod_log_rewind+0x1b4/0x200<br /> RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293<br /> RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000<br /> RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00<br /> RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001<br /> R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00<br /> FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> btrfs_get_old_root+0x12b/0x420<br /> btrfs_search_old_slot+0x64/0x2f0<br /> ? tree_mod_log_oldest_root+0x3d/0xf0<br /> resolve_indirect_ref+0xfd/0x660<br /> ? ulist_alloc+0x31/0x60<br /> ? kmem_cache_alloc_trace+0x114/0x2c0<br /> find_parent_nodes+0x97a/0x17e0<br /> ? ulist_alloc+0x30/0x60<br /> btrfs_find_all_roots_safe+0x97/0x150<br /> iterate_extent_inodes+0x154/0x370<br /> ? btrfs_search_path_in_tree+0x240/0x240<br /> iterate_inodes_from_logical+0x98/0xd0<br /> ? btrfs_search_path_in_tree+0x240/0x240<br /> btrfs_ioctl_logical_to_ino+0xd9/0x180<br /> btrfs_ioctl+0xe2/0x2ec0<br /> ? __mod_memcg_lruvec_state+0x3d/0x280<br /> ? do_sys_openat2+0x6d/0x140<br /> ? kretprobe_dispatcher+0x47/0x70<br /> ? kretprobe_rethook_handler+0x38/0x50<br /> ? rethook_trampoline_handler+0x82/0x140<br /> ? arch_rethook_trampoline_callback+0x3b/0x50<br /> ? kmem_cache_free+0xfb/0x270<br /> ? do_sys_openat2+0xd5/0x140<br /> __x64_sys_ioctl+0x71/0xb0<br /> do_syscall_64+0x2d/0x40<br /> <br /> Which is this code in tree_mod_log_rewind()<br /> <br /> switch (tm-&gt;op) {<br /> case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING:<br /> BUG_ON(tm-&gt;slot From here the bug is triggered by the following steps<br /> <br /> 1. Call btrfs_get_old_root() on the new_root.<br /> 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is<br /> currently logical 0.<br /> 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which<br /> gives us the KEY_REPLACE seq 2, and since that&amp;#39;s not a<br /> LOG_ROOT_REPLACE we incorrectly believe that we don&amp;#39;t have an old<br /> root, because we expect that the most recent change should be a<br /> LOG_ROOT_REPLACE.<br /> 4. Back in tree_mod_log_oldest_root() we don&amp;#39;t have a LOG_ROOT_REPLACE,<br /> so we don&amp;#39;t set old_root, we simply use our e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: stop using keyrings subsystem for fscrypt_master_key<br /> <br /> The approach of fs/crypto/ internally managing the fscrypt_master_key<br /> structs as the payloads of "struct key" objects contained in a<br /> "struct key" keyring has outlived its usefulness. The original idea was<br /> to simplify the code by reusing code from the keyrings subsystem.<br /> However, several issues have arisen that can&amp;#39;t easily be resolved:<br /> <br /> - When a master key struct is destroyed, blk_crypto_evict_key() must be<br /> called on any per-mode keys embedded in it. (This started being the<br /> case when inline encryption support was added.) Yet, the keyrings<br /> subsystem can arbitrarily delay the destruction of keys, even past the<br /> time the filesystem was unmounted. Therefore, currently there is no<br /> easy way to call blk_crypto_evict_key() when a master key is<br /> destroyed. Currently, this is worked around by holding an extra<br /> reference to the filesystem&amp;#39;s request_queue(s). But it was overlooked<br /> that the request_queue reference is *not* guaranteed to pin the<br /> corresponding blk_crypto_profile too; for device-mapper devices that<br /> support inline crypto, it doesn&amp;#39;t. This can cause a use-after-free.<br /> <br /> - When the last inode that was using an incompletely-removed master key<br /> is evicted, the master key removal is completed by removing the key<br /> struct from the keyring. Currently this is done via key_invalidate().<br /> Yet, key_invalidate() takes the key semaphore. This can deadlock when<br /> called from the shrinker, since in fscrypt_ioctl_add_key(), memory is<br /> allocated with GFP_KERNEL under the same semaphore.<br /> <br /> - More generally, the fact that the keyrings subsystem can arbitrarily<br /> delay the destruction of keys (via garbage collection delay, or via<br /> random processes getting temporary key references) is undesirable, as<br /> it means we can&amp;#39;t strictly guarantee that all secrets are ever wiped.<br /> <br /> - Doing the master key lookups via the keyrings subsystem results in the<br /> key_permission LSM hook being called. fscrypt doesn&amp;#39;t want this, as<br /> all access control for encrypted files is designed to happen via the<br /> files themselves, like any other files. The workaround which SELinux<br /> users are using is to change their SELinux policy to grant key search<br /> access to all domains. This works, but it is an odd extra step that<br /> shouldn&amp;#39;t really have to be done.<br /> <br /> The fix for all these issues is to change the implementation to what I<br /> should have done originally: don&amp;#39;t use the keyrings subsystem to keep<br /> track of the filesystem&amp;#39;s fscrypt_master_key structs. Instead, just<br /> store them in a regular kernel data structure, and rework the reference<br /> counting, locking, and lifetime accordingly. Retain support for<br /> RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()<br /> with fscrypt_sb_delete(), which releases the keys synchronously and runs<br /> a bit earlier during unmount, so that block devices are still available.<br /> <br /> A side effect of this patch is that neither the master keys themselves<br /> nor the filesystem keyrings will be listed in /proc/keys anymore.<br /> ("Master key users" and the master key users keyrings will still be<br /> listed.) However, this was mostly an implementation detail, and it was<br /> intended just for debugging purposes. I don&amp;#39;t know of anyone using it.<br /> <br /> This patch does *not* change how "master key users" (-&gt;mk_users) works;<br /> that still uses the keyrings subsystem. That is still needed for key<br /> quotas, and changing that isn&amp;#39;t necessary to solve the issues listed<br /> above. If we decide to change that too, it would be a separate patch.<br /> <br /> I&amp;#39;ve marked this as fixing the original commit that added the fscrypt<br /> keyring, but as noted above the most important issue that this patch<br /> fixes wasn&amp;#39;t introduced until the addition of inline encryption support.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/pmem: Fix cxl_pmem_region and cxl_memdev leak<br /> <br /> When a cxl_nvdimm object goes through a -&gt;remove() event (device<br /> physically removed, nvdimm-bridge disabled, or nvdimm device disabled),<br /> then any associated regions must also be disabled. As highlighted by the<br /> cxl-create-region.sh test [1], a single device may host multiple<br /> regions, but the driver was only tracking one region at a time. This<br /> leads to a situation where only the last enabled region per nvdimm<br /> device is cleaned up properly. Other regions are leaked, and this also<br /> causes cxl_memdev reference leaks.<br /> <br /> Fix the tracking by allowing cxl_nvdimm objects to track multiple region<br /> associations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix decoder allocation crash<br /> <br /> When an intermediate port&amp;#39;s decoders have been exhausted by existing<br /> regions, and creating a new region with the port in question in it&amp;#39;s<br /> hierarchical path is attempted, cxl_port_attach_region() fails to find a<br /> port decoder (as would be expected), and drops into the failure / cleanup<br /> path.<br /> <br /> However, during cleanup of the region reference, a sanity check attempts<br /> to dereference the decoder, which in the above case didn&amp;#39;t exist. This<br /> causes a NULL pointer dereference BUG.<br /> <br /> To fix this, refactor the decoder allocation and de-allocation into<br /> helper routines, and in this &amp;#39;free&amp;#39; routine, check that the decoder,<br /> @cxld, is valid before attempting any operations on it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix region HPA ordering validation<br /> <br /> Some regions may not have any address space allocated. Skip them when<br /> validating HPA order otherwise a crash like the following may result:<br /> <br /> devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [..]<br /> RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> kernfs_fop_write_iter+0x144/0x200<br /> vfs_write+0x24a/0x4d0<br /> ksys_write+0x69/0xf0<br /> do_syscall_64+0x3a/0x90<br /> <br /> store_targetN+0x655/0x1740:<br /> alloc_region_ref at drivers/cxl/core/region.c:676<br /> (inlined by) cxl_port_attach_region at drivers/cxl/core/region.c:850<br /> (inlined by) cxl_region_attach at drivers/cxl/core/region.c:1290<br /> (inlined by) attach_target at drivers/cxl/core/region.c:1410<br /> (inlined by) store_targetN at drivers/cxl/core/region.c:1453

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix use-after-free for dynamic ftrace_ops<br /> <br /> KASAN reported a use-after-free with ftrace ops [1]. It was found from<br /> vmcore that perf had registered two ops with the same content<br /> successively, both dynamic. After unregistering the second ops, a<br /> use-after-free occurred.<br /> <br /> In ftrace_shutdown(), when the second ops is unregistered, the<br /> FTRACE_UPDATE_CALLS command is not set because there is another enabled<br /> ops with the same content. Also, both ops are dynamic and the ftrace<br /> callback function is ftrace_ops_list_func, so the<br /> FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value<br /> of &amp;#39;command&amp;#39; will be 0 and ftrace_shutdown() will skip the rcu<br /> synchronization.<br /> <br /> However, ftrace may be activated. When the ops is released, another CPU<br /> may be accessing the ops. Add the missing synchronization to fix this<br /> problem.<br /> <br /> [1]<br /> BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]<br /> BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049<br /> Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468<br /> <br /> CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132<br /> show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x1b4/0x248 lib/dump_stack.c:118<br /> print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387<br /> __kasan_report mm/kasan/report.c:547 [inline]<br /> kasan_report+0x118/0x210 mm/kasan/report.c:564<br /> check_memory_region_inline mm/kasan/generic.c:187 [inline]<br /> __asan_load8+0x98/0xc0 mm/kasan/generic.c:253<br /> __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]<br /> ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049<br /> ftrace_graph_call+0x0/0x4<br /> __might_sleep+0x8/0x100 include/linux/perf_event.h:1170<br /> __might_fault mm/memory.c:5183 [inline]<br /> __might_fault+0x58/0x70 mm/memory.c:5171<br /> do_strncpy_from_user lib/strncpy_from_user.c:41 [inline]<br /> strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139<br /> getname_flags+0xb0/0x31c fs/namei.c:149<br /> getname+0x2c/0x40 fs/namei.c:209<br /> [...]<br /> <br /> Allocated by task 14445:<br /> kasan_save_stack+0x24/0x50 mm/kasan/common.c:48<br /> kasan_set_track mm/kasan/common.c:56 [inline]<br /> __kasan_kmalloc mm/kasan/common.c:479 [inline]<br /> __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449<br /> kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493<br /> kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950<br /> kmalloc include/linux/slab.h:563 [inline]<br /> kzalloc include/linux/slab.h:675 [inline]<br /> perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230<br /> perf_event_alloc kernel/events/core.c:11733 [inline]<br /> __do_sys_perf_event_open kernel/events/core.c:11831 [inline]<br /> __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723<br /> __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723<br /> [...]<br /> <br /> Freed by task 14445:<br /> kasan_save_stack+0x24/0x50 mm/kasan/common.c:48<br /> kasan_set_track+0x24/0x34 mm/kasan/common.c:56<br /> kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358<br /> __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437<br /> __kasan_slab_free mm/kasan/common.c:445 [inline]<br /> kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446<br /> slab_free_hook mm/slub.c:1569 [inline]<br /> slab_free_freelist_hook mm/slub.c:1608 [inline]<br /> slab_free mm/slub.c:3179 [inline]<br /> kfree+0x12c/0xc10 mm/slub.c:4176<br /> perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434<br /> perf_event_alloc kernel/events/core.c:11733 [inline]<br /> __do_sys_perf_event_open kernel/events/core.c:11831 [inline]<br /> __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()<br /> <br /> test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak<br /> when there is no failure. Move kfree(buf) from fail path to common path<br /> to prevent the memleak. The same reason and solution in<br /> test_gen_kretprobe_cmd().<br /> <br /> unreferenced object 0xffff888143b14000 (size 2048):<br /> comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)<br /> hex dump (first 32 bytes):<br /> 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp<br /> 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] 0xffffffffa059006f<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x3006/0x3390<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> capabilities: fix potential memleak on error path from vfs_getxattr_alloc()<br /> <br /> In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to<br /> complete the memory allocation of tmpbuf, if we have completed<br /> the memory allocation of tmpbuf, but failed to call handler-&gt;get(...),<br /> there will be a memleak in below logic:<br /> <br /> |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)<br /> | /* ^^^ alloc for tmpbuf */<br /> |-- value = krealloc(*xattr_value, error + 1, flags)<br /> | /* ^^^ alloc memory */<br /> |-- error = handler-&gt;get(handler, ...)<br /> | /* error! */<br /> |-- *xattr_value = value<br /> | /* xattr_value is &amp;tmpbuf (memory leak!) */<br /> <br /> So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.<br /> <br /> [PM: subject line and backtrace tweaks]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache<br /> <br /> Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.<br /> Not checking the active flag during refresh is particularly egregious, as<br /> KVM can end up with a valid, inactive cache, which can lead to a variety<br /> of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing<br /> an mmu_notifier invalidation due to the cache not being on the list of<br /> gfns to invalidate.<br /> <br /> Note, "active" needs to be set if and only if the cache is on the list<br /> of caches, i.e. is reachable via mmu_notifier events. If a relevant<br /> mmu_notifier event occurs while the cache is "active" but not on the<br /> list, KVM will not acquire the cache&amp;#39;s lock and so will not serailize<br /> the mmu_notifier event with active users and/or kvm_gpc_refresh().<br /> <br /> A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND<br /> can be exploited to trigger the bug.<br /> <br /> 1. Deactivate shinfo cache:<br /> <br /> kvm_xen_hvm_set_attr<br /> case KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> kvm_gpc_deactivate<br /> kvm_gpc_unmap<br /> gpc-&gt;valid = false<br /> gpc-&gt;khva = NULL<br /> gpc-&gt;active = false<br /> <br /> Result: active = false, valid = false<br /> <br /> 2. Cause cache refresh:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> kvm_gpc_check<br /> return -EWOULDBLOCK because !gpc-&gt;valid<br /> kvm_xen_set_evtchn_fast<br /> return -EWOULDBLOCK<br /> kvm_gpc_refresh<br /> hva_to_pfn_retry<br /> gpc-&gt;valid = true<br /> gpc-&gt;khva = not NULL<br /> <br /> Result: active = false, valid = true<br /> <br /> 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> read_lock gpc-&gt;lock<br /> kvm_xen_hvm_set_attr case<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> mutex_lock kvm-&gt;lock<br /> kvm_xen_shared_info_init<br /> kvm_gpc_activate<br /> gpc-&gt;khva = NULL<br /> kvm_gpc_check<br /> [ Check passes because gpc-&gt;valid is<br /> still true, even though gpc-&gt;khva<br /> is already NULL. ]<br /> shinfo = gpc-&gt;khva<br /> pending_bits = shinfo-&gt;evtchn_pending<br /> CRASH: test_and_set_bit(..., pending_bits)