Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: huge_memory: don&amp;#39;t force huge page alignment on 32 bit<br /> <br /> commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP<br /> boundaries") caused two issues [1] [2] reported on 32 bit system or compat<br /> userspace.<br /> <br /> It doesn&amp;#39;t make too much sense to force huge page alignment on 32 bit<br /> system due to the constrained virtual address space.<br /> <br /> [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/<br /> [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

Cross Site Scripting (XSS) vulnerability in hexo-theme-anzhiyu v1.6.12, allows remote attackers to execute arbitrary code via the algolia search function.

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

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

If an attacked was given access to an instance with the admin or manager role there is no backend authentication that would prevent the attacked from creating a new user with an `admin` role and then be able to use this new account to have elevated privileges on the instance

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Only call folio_start_fscache() one time for each folio<br /> <br /> If a network filesystem using netfs implements a clamp_length()<br /> function, it can set subrequest lengths smaller than a page size.<br /> <br /> When we loop through the folios in netfs_rreq_unlock_folios() to<br /> set any folios to be written back, we need to make sure we only<br /> call folio_start_fscache() once for each folio.<br /> <br /> Otherwise, this simple testcase:<br /> <br /> mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs<br /> dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1<br /> 1+0 records in<br /> 1+0 records out<br /> 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s<br /> echo 3 &gt; /proc/sys/vm/drop_caches<br /> cat /mnt/nfs/file.bin &gt; /dev/null<br /> <br /> will trigger an oops similar to the following:<br /> <br /> page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/netfs.h:44!<br /> ...<br /> CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5<br /> ...<br /> RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]<br /> ...<br /> Call Trace:<br /> netfs_rreq_assess+0x497/0x660 [netfs]<br /> netfs_subreq_terminated+0x32b/0x610 [netfs]<br /> nfs_netfs_read_completion+0x14e/0x1a0 [nfs]<br /> nfs_read_completion+0x2f9/0x330 [nfs]<br /> rpc_free_task+0x72/0xa0 [sunrpc]<br /> rpc_async_release+0x46/0x70 [sunrpc]<br /> process_one_work+0x3bd/0x710<br /> worker_thread+0x89/0x610<br /> kthread+0x181/0x1c0<br /> ret_from_fork+0x29/0x50

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/core: Fix ETH_P_1588 flow dissector<br /> <br /> When a PTP ethernet raw frame with a size of more than 256 bytes followed<br /> by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation<br /> is wrong. For example: hdr-&gt;message_length takes the wrong value (0xffff)<br /> and it does not replicate real header length. In this case, &amp;#39;nhoff&amp;#39; value<br /> was overridden and the PTP header was badly dissected. This leads to a<br /> kernel crash.<br /> <br /> net/core: flow_dissector<br /> net/core flow dissector nhoff = 0x0000000e<br /> net/core flow dissector hdr-&gt;message_length = 0x0000ffff<br /> net/core flow dissector nhoff = 0x0001000d (u16 overflow)<br /> ...<br /> skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88<br /> skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> <br /> Using the size of the ptp_header struct will allow the corrected<br /> calculation of the nhoff value.<br /> <br /> net/core flow dissector nhoff = 0x0000000e<br /> net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)<br /> ...<br /> skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff<br /> skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> <br /> Kernel trace:<br /> [ 74.984279] ------------[ cut here ]------------<br /> [ 74.989471] kernel BUG at include/linux/skbuff.h:2440!<br /> [ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1<br /> [ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023<br /> [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130<br /> [ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9<br /> [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297<br /> [ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003<br /> [ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300<br /> [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800<br /> [ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010<br /> [ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800<br /> [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000<br /> [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0<br /> [ 75.121980] PKRU: 55555554<br /> [ 75.125035] Call Trace:<br /> [ 75.127792] <br /> [ 75.130063] ? eth_get_headlen+0xa4/0xc0<br /> [ 75.134472] igc_process_skb_fields+0xcd/0x150<br /> [ 75.139461] igc_poll+0xc80/0x17b0<br /> [ 75.143272] __napi_poll+0x27/0x170<br /> [ 75.147192] net_rx_action+0x234/0x280<br /> [ 75.151409] __do_softirq+0xef/0x2f4<br /> [ 75.155424] irq_exit_rcu+0xc7/0x110<br /> [ 75.159432] common_interrupt+0xb8/0xd0<br /> [ 75.163748] <br /> [ 75.166112] <br /> [ 75.168473] asm_common_interrupt+0x22/0x40<br /> [ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350<br /> [ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1<br /> [ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202<br /> [ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f<br /> [ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20<br /> [ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001<br /> [ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980<br /> [ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000<br /> [ 75.245635] ? <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: Fix possible NULL-pointer dereference<br /> <br /> In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists<br /> before dereferencing it as rdma_set_service_type() argument<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/mdev: Fix a null-ptr-deref bug for mdev_unregister_parent()<br /> <br /> Inject fault while probing mdpy.ko, if kstrdup() of create_dir() fails in<br /> kobject_add_internal() in kobject_init_and_add() in mdev_type_add()<br /> in parent_create_sysfs_files(), it will return 0 and probe successfully.<br /> And when rmmod mdpy.ko, the mdpy_dev_exit() will call<br /> mdev_unregister_parent(), the mdev_type_remove() may traverse uninitialized<br /> parent-&gt;types[i] in parent_remove_sysfs_files(), and it will cause<br /> below null-ptr-deref.<br /> <br /> If mdev_type_add() fails, return the error code and kset_unregister()<br /> to fix the issue.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 2 PID: 10215 Comm: rmmod Tainted: G W N 6.6.0-rc2+ #20<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:__kobject_del+0x62/0x1c0<br /> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8<br /> RSP: 0018:ffff88810695fd30 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1<br /> R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000<br /> R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660<br /> FS: 00007fbc81981540(0000) GS:ffff888119d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc14a142dc0 CR3: 0000000110a62003 CR4: 0000000000770ee0<br /> DR0: ffffffff8fb0bce8 DR1: ffffffff8fb0bce9 DR2: ffffffff8fb0bcea<br /> DR3: ffffffff8fb0bceb DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die_addr+0x3d/0xa0<br /> ? exc_general_protection+0x144/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? __kobject_del+0x62/0x1c0<br /> kobject_del+0x32/0x50<br /> parent_remove_sysfs_files+0xd6/0x170 [mdev]<br /> mdev_unregister_parent+0xfb/0x190 [mdev]<br /> ? mdev_register_parent+0x270/0x270 [mdev]<br /> ? find_module_all+0x9d/0xe0<br /> mdpy_dev_exit+0x17/0x63 [mdpy]<br /> __do_sys_delete_module.constprop.0+0x2fa/0x4b0<br /> ? module_flags+0x300/0x300<br /> ? __fput+0x4e7/0xa00<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fbc813221b7<br /> Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe780e0648 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0<br /> RAX: ffffffffffffffda RBX: 00007ffe780e06a8 RCX: 00007fbc813221b7<br /> RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055e214df9b58<br /> RBP: 000055e214df9af0 R08: 00007ffe780df5c1 R09: 0000000000000000<br /> R10: 00007fbc8139ecc0 R11: 0000000000000206 R12: 00007ffe780e0870<br /> R13: 00007ffe780e0ed0 R14: 000055e214df9260 R15: 000055e214df9af0<br /> <br /> Modules linked in: mdpy(-) mdev vfio_iommu_type1 vfio [last unloaded: mdpy]<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:__kobject_del+0x62/0x1c0<br /> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8<br /> RSP: 0018:ffff88810695fd30 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1<br /> R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000<br /> R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660<br /> FS: 00007fbc81981540(0000) GS:ffff888119d00000(000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: fix null-ptr-deref when team device type is changed<br /> <br /> Get a null-ptr-deref bug as follows with reproducer [1].<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000228<br /> ...<br /> RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]<br /> ...<br /> Call Trace:<br /> <br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x82/0x150<br /> ? exc_page_fault+0x69/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? vlan_dev_hard_header+0x35/0x140 [8021q]<br /> ? vlan_dev_hard_header+0x8e/0x140 [8021q]<br /> neigh_connected_output+0xb2/0x100<br /> ip6_finish_output2+0x1cb/0x520<br /> ? nf_hook_slow+0x43/0xc0<br /> ? ip6_mtu+0x46/0x80<br /> ip6_finish_output+0x2a/0xb0<br /> mld_sendpack+0x18f/0x250<br /> mld_ifc_work+0x39/0x160<br /> process_one_work+0x1e6/0x3f0<br /> worker_thread+0x4d/0x2f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe5/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> [1]<br /> $ teamd -t team0 -d -c &amp;#39;{"runner": {"name": "loadbalance"}}&amp;#39;<br /> $ ip link add name t-dummy type dummy<br /> $ ip link add link t-dummy name t-dummy.100 type vlan id 100<br /> $ ip link add name t-nlmon type nlmon<br /> $ ip link set t-nlmon master team0<br /> $ ip link set t-nlmon nomaster<br /> $ ip link set t-dummy up<br /> $ ip link set team0 up<br /> $ ip link set t-dummy.100 down<br /> $ ip link set t-dummy.100 master team0<br /> <br /> When enslave a vlan device to team device and team device type is changed<br /> from non-ether to ether, header_ops of team device is changed to<br /> vlan_header_ops. That is incorrect and will trigger null-ptr-deref<br /> for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not<br /> a vlan device.<br /> <br /> Cache eth_header_ops in team_setup(), then assign cached header_ops to<br /> header_ops of team net device when its type is changed from non-ether<br /> to ether to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp: fix dccp_v4_err()/dccp_v6_err() again<br /> <br /> dh-&gt;dccph_x is the 9th byte (offset 8) in "struct dccp_hdr",<br /> not in the "byte 7" as Jann claimed.<br /> <br /> We need to make sure the ICMP messages are big enough,<br /> using more standard ways (no more assumptions).<br /> <br /> syzbot reported:<br /> BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]<br /> BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline]<br /> BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94<br /> pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]<br /> pskb_may_pull include/linux/skbuff.h:2681 [inline]<br /> dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94<br /> icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867<br /> icmpv6_rcv+0x19d5/0x30d0<br /> ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438<br /> ip6_input_finish net/ipv6/ip6_input.c:483 [inline]<br /> NF_HOOK include/linux/netfilter.h:304 [inline]<br /> ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492<br /> ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586<br /> dst_input include/net/dst.h:468 [inline]<br /> ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:304 [inline]<br /> ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310<br /> __netif_receive_skb_one_core net/core/dev.c:5523 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637<br /> netif_receive_skb_internal net/core/dev.c:5723 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5782<br /> tun_rx_batched+0x83b/0x920<br /> tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048<br /> call_write_iter include/linux/fs.h:1985 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x8ef/0x15c0 fs/read_write.c:584<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:637<br /> __do_sys_write fs/read_write.c:649 [inline]<br /> __se_sys_write fs/read_write.c:646 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:646<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559<br /> __alloc_skb+0x318/0x740 net/core/skbuff.c:650<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313<br /> sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795<br /> tun_alloc_skb drivers/net/tun.c:1531 [inline]<br /> tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048<br /> call_write_iter include/linux/fs.h:1985 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x8ef/0x15c0 fs/read_write.c:584<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:637<br /> __do_sys_write fs/read_write.c:649 [inline]<br /> __se_sys_write fs/read_write.c:646 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:646<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race<br /> <br /> The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an<br /> enclave and set secs.epc_page to NULL. The SECS page is used for EAUG<br /> and ELDU in the SGX page fault handler. However, the NULL check for<br /> secs.epc_page is only done for ELDU, not EAUG before being used.<br /> <br /> Fix this by doing the same NULL check and reloading of the SECS page as<br /> needed for both EAUG and ELDU.<br /> <br /> The SECS page holds global enclave metadata. It can only be reclaimed<br /> when there are no other enclave pages remaining. At that point,<br /> virtually nothing can be done with the enclave until the SECS page is<br /> paged back in.<br /> <br /> An enclave can not run nor generate page faults without a resident SECS<br /> page. But it is still possible for a #PF for a non-SECS page to race<br /> with paging out the SECS page: when the last resident non-SECS page A<br /> triggers a #PF in a non-resident page B, and then page A and the SECS<br /> both are paged out before the #PF on B is handled.<br /> <br /> Hitting this bug requires that race triggered with a #PF for EAUG.<br /> Following is a trace when it happens.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:sgx_encl_eaug_page+0xc7/0x210<br /> Call Trace:<br /> ? __kmem_cache_alloc_node+0x16a/0x440<br /> ? xa_load+0x6e/0xa0<br /> sgx_vma_fault+0x119/0x230<br /> __do_fault+0x36/0x140<br /> do_fault+0x12f/0x400<br /> __handle_mm_fault+0x728/0x1110<br /> handle_mm_fault+0x105/0x310<br /> do_user_addr_fault+0x1ee/0x750<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> exc_page_fault+0x76/0x180<br /> asm_exc_page_fault+0x27/0x30