Vulnerabilities

Flags SDK is an open-source feature flags toolkit for Next.js and SvelteKit. Impacted versions include flags from 3.2.0 and prior and @vercel/flags from 3.1.1 and prior as certain circumstances allows a bad actor with detailed knowledge of the vulnerability to list all flags returned by the flags discovery endpoint (.well-known/vercel/flags). This vulnerability allows for information disclosure, where a bad actor could gain access to a list of all feature flags exposed through the flags discovery endpoint, including the flag names, flag descriptions, available options and their labels (e.g. true, false), and default flag values. This issue has been patched in flags@4.0.0, users of flags and @vercel/flags should also migrate to flags@4.0.0.

Vault Community, Vault Enterprise (“Vault”) Azure Auth method did not correctly validate the claims in the Azure-issued token, resulting in the potential bypass of the bound_locations parameter on login. Fixed in Vault Community Edition 1.19.1 and Vault Enterprise 1.19.1, 1.18.7, 1.17.14, 1.16.18.

A vulnerability classified as critical was found in Casdoor up to 1.811.0. This vulnerability affects the function HandleScim of the file controllers/scim.go of the component SCIM User Creation Endpoint. The manipulation leads to authorization bypass. The attack can be initiated remotely. Upgrading to version 1.812.0 is able to address this issue. The name of the patch is 3d12ac8dc2282369296c3386815c00a06c6a92fe. It is recommended to upgrade the affected component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms<br /> <br /> As the call trace shown, the root cause is kunmap incorrect pages:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000<br /> CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4<br /> Workqueue: erofs_worker z_erofs_decompressqueue_work<br /> EIP: z_erofs_lzma_decompress+0x34b/0x8ac<br /> z_erofs_decompress+0x12/0x14<br /> z_erofs_decompress_queue+0x7e7/0xb1c<br /> z_erofs_decompressqueue_work+0x32/0x60<br /> process_one_work+0x24b/0x4d8<br /> ? process_one_work+0x1a4/0x4d8<br /> worker_thread+0x14c/0x3fc<br /> kthread+0xe6/0x10c<br /> ? rescuer_thread+0x358/0x358<br /> ? kthread_complete_and_exit+0x18/0x18<br /> ret_from_fork+0x1c/0x28<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bug is trivial and should be fixed now. It has no impact on<br /> !HIGHMEM platforms.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix another off-by-one fsmap error on 1k block filesystems<br /> <br /> Apparently syzbot figured out that issuing this FSMAP call:<br /> <br /> struct fsmap_head cmd = {<br /> .fmh_count = ...;<br /> .fmh_keys = {<br /> { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },<br /> { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },<br /> },<br /> ...<br /> };<br /> ret = ioctl(fd, FS_IOC_GETFSMAP, &amp;cmd);<br /> <br /> Produces this crash if the underlying filesystem is a 1k-block ext4<br /> filesystem:<br /> <br /> kernel BUG at fs/ext4/ext4.h:3331!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]<br /> RSP: 0018:ffffc90007c03998 EFLAGS: 00010246<br /> RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000<br /> RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11<br /> RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400<br /> R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001<br /> R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398<br /> FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> __x64_sys_ioctl+0x82/0xa0<br /> do_syscall_64+0x2b/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fdf20558aff<br /> RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff<br /> RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003<br /> RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010<br /> R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000<br /> <br /> For GETFSMAP calls, the caller selects a physical block device by<br /> writing its block number into fsmap_head.fmh_keys[01].fmr_device.<br /> To query mappings for a subrange of the device, the starting byte of the<br /> range is written to fsmap_head.fmh_keys[0].fmr_physical and the last<br /> byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.<br /> <br /> IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you&amp;#39;d<br /> set the inputs as follows:<br /> <br /> fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},<br /> fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},<br /> <br /> Which would return you whatever is mapped in the 12 bytes starting at<br /> physical offset 3.<br /> <br /> The crash is due to insufficient range validation of keys[1] in<br /> ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of<br /> the filesystem, which means that s_first_data_block is nonzero.<br /> ext4_get_group_no_and_offset subtracts this quantity from the blocknr<br /> argument before cracking it into a group number and a block number<br /> within a group. IOWs, block group 0 spans blocks 1-8192 (1-based)<br /> instead of 0-8191 (0-based) like what happens with larger blocksizes.<br /> <br /> The net result of this encoding is that blocknr s_first_data_block);<br /> <br /> The division then operates on -1:<br /> <br /> offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) &gt;&gt;<br /> EXT4_SB(sb)-&gt;s_cluster_bits;<br /> <br /> Leaving an impossibly large group number (2^32-1) in blocknr.<br /> ext4_getfsmap_check_keys checked that keys[0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: copy last block omitted in ice_get_module_eeprom()<br /> <br /> ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice:<br /> Reimplement module reads used by ethtool") In this refactor,<br /> ice_get_module_eeprom() reads the eeprom in blocks of size 8.<br /> But the condition that should protect the buffer overflow<br /> ignores the last block. The last block always contains zeros.<br /> <br /> Bug uncovered by ethtool upstream commit 9538f384b535<br /> ("netlink: eeprom: Defer page requests to individual parsers")<br /> After this commit, ethtool reads a block with length = 1;<br /> to read the SFF-8024 identifier value.<br /> <br /> unpatched driver:<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 8<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 00 00 00 00 00 00<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 12<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00<br /> $<br /> <br /> $ ethtool -m enp65s0f0np0<br /> Offset Values<br /> ------ ------<br /> 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00<br /> 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> <br /> patched driver:<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 8<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c<br /> $ ethtool -m enp65s0f0np0 offset 0x90 length 12<br /> Offset Values<br /> ------ ------<br /> 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78<br /> $ ethtool -m enp65s0f0np0<br /> Identifier : 0x11 (QSFP28)<br /> Extended identifier : 0x00<br /> Extended identifier description : 1.5W max. Power consumption<br /> Extended identifier description : No CDR in TX, No CDR in RX<br /> Extended identifier description : High Power Class (&gt; 3.5 W) not enabled<br /> Connector : 0x23 (No separable connector)<br /> Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00<br /> Transceiver type : 40G Ethernet: 40G Base-CR4<br /> Transceiver type : 25G Ethernet: 25G Base-CR CA-N<br /> Encoding : 0x05 (64B/66B)<br /> BR, Nominal : 25500Mbps<br /> Rate identifier : 0x00<br /> Length (SMF,km) : 0km<br /> Length (OM3 50um) : 0m<br /> Length (OM2 50um) : 0m<br /> Length (OM1 62.5um) : 0m<br /> Length (Copper or Active cable) : 1m<br /> Transmitter technology : 0xa0 (Copper cable unequalized)<br /> Attenuation at 2.5GHz : 4db<br /> Attenuation at 5.0GHz : 5db<br /> Attenuation at 7.0GHz : 7db<br /> Attenuation at 12.9GHz : 10db<br /> ........<br /> ....

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()<br /> <br /> ila_xlat_nl_cmd_get_mapping() generates an empty skb,<br /> triggerring a recent sanity check [1].<br /> <br /> Instead, return an error code, so that user space<br /> can get it.<br /> <br /> [1]<br /> skb_assert_len<br /> WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> Modules linked in:<br /> CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> lr : skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> sp : ffff80001e0d6c40<br /> x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0<br /> x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00<br /> x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10<br /> x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0<br /> x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001<br /> x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600<br /> x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744<br /> x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e<br /> Call trace:<br /> skb_assert_len include/linux/skbuff.h:2527 [inline]<br /> __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156<br /> dev_queue_xmit include/linux/netdevice.h:3033 [inline]<br /> __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]<br /> __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325<br /> netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338<br /> __netlink_sendskb net/netlink/af_netlink.c:1283 [inline]<br /> netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292<br /> netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380<br /> nlmsg_unicast include/net/netlink.h:1099 [inline]<br /> genlmsg_unicast include/net/genetlink.h:433 [inline]<br /> genlmsg_reply include/net/genetlink.h:443 [inline]<br /> ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]<br /> genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065<br /> netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574<br /> genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0x558/0x844 net/socket.c:2479<br /> ___sys_sendmsg net/socket.c:2533 [inline]<br /> __sys_sendmsg+0x26c/0x33c net/socket.c:2562<br /> __do_sys_sendmsg net/socket.c:2571 [inline]<br /> __se_sys_sendmsg net/socket.c:2569 [inline]<br /> __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193<br /> el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591<br /> irq event stamp: 136484<br /> hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345<br /> hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405<br /> softirqs last enabled at (136418): [] softirq_ha<br /> ---truncated---

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 /> scsi: core: Remove the /proc/scsi/${proc_name} directory earlier<br /> <br /> Remove the /proc/scsi/${proc_name} directory earlier to fix a race<br /> condition between unloading and reloading kernel modules. This fixes a bug<br /> introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in<br /> the SCSI core").<br /> <br /> Fix the following kernel warning:<br /> <br /> proc_dir_entry &amp;#39;scsi/scsi_debug&amp;#39; already registered<br /> WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0<br /> Call Trace:<br /> proc_mkdir+0xb5/0xe0<br /> scsi_proc_hostdir_add+0xb5/0x170<br /> scsi_host_alloc+0x683/0x6c0<br /> sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]<br /> really_probe+0x159/0x540<br /> __driver_probe_device+0xdc/0x230<br /> driver_probe_device+0x4f/0x120<br /> __device_attach_driver+0xef/0x180<br /> bus_for_each_drv+0xe5/0x130<br /> __device_attach+0x127/0x290<br /> device_initial_probe+0x17/0x20<br /> bus_probe_device+0x110/0x130<br /> device_add+0x673/0xc80<br /> device_register+0x1e/0x30<br /> sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]<br /> scsi_debug_init+0x64f/0x1000 [scsi_debug]<br /> do_one_initcall+0xd7/0x470<br /> do_init_module+0xe7/0x330<br /> load_module+0x122a/0x12c0<br /> __do_sys_finit_module+0x124/0x1a0<br /> __x64_sys_finit_module+0x46/0x50<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties<br /> <br /> devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause<br /> out-of-bounds write in device_property_read_u8_array later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: caif: Fix use-after-free in cfusbl_device_notify()<br /> <br /> syzbot reported use-after-free in cfusbl_device_notify() [1]. This<br /> causes a stack trace like below:<br /> <br /> BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214<br /> <br /> CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313<br /> print_report mm/kasan/report.c:429 [inline]<br /> kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491<br /> cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> notifier_call_chain+0xb5/0x200 kernel/notifier.c:87<br /> call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945<br /> call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]<br /> call_netdevice_notifiers net/core/dev.c:1997 [inline]<br /> netdev_wait_allrefs_any net/core/dev.c:10227 [inline]<br /> netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341<br /> default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334<br /> ops_exit_list+0x125/0x170 net/core/net_namespace.c:167<br /> cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br /> <br /> <br /> When unregistering a net device, unregister_netdevice_many_notify()<br /> sets the device&amp;#39;s reg_state to NETREG_UNREGISTERING, calls notifiers<br /> with NETDEV_UNREGISTER, and adds the device to the todo list.<br /> <br /> Later on, devices in the todo list are processed by netdev_run_todo().<br /> netdev_run_todo() waits devices&amp;#39; reference count become 1 while<br /> rebdoadcasting NETDEV_UNREGISTER notification.<br /> <br /> When cfusbl_device_notify() is called with NETDEV_UNREGISTER multiple<br /> times, the parent device might be freed. This could cause UAF.<br /> Processing NETDEV_UNREGISTER multiple times also causes inbalance of<br /> reference count for the module.<br /> <br /> This patch fixes the issue by accepting only first NETDEV_UNREGISTER<br /> notification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: fix struct pid leaks in OOB support<br /> <br /> syzbot reported struct pid leak [1].<br /> <br /> Issue is that queue_oob() calls maybe_add_creds() which potentially<br /> holds a reference on a pid.<br /> <br /> But skb-&gt;destructor is not set (either directly or by calling<br /> unix_scm_to_skb())<br /> <br /> This means that subsequent kfree_skb() or consume_skb() would leak<br /> this reference.<br /> <br /> In this fix, I chose to fully support scm even for the OOB message.<br /> <br /> [1]<br /> BUG: memory leak<br /> unreferenced object 0xffff8881053e7f80 (size 128):<br /> comm "syz-executor242", pid 5066, jiffies 4294946079 (age 13.220s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] alloc_pid+0x6a/0x560 kernel/pid.c:180<br /> [] copy_process+0x169f/0x26c0 kernel/fork.c:2285<br /> [] kernel_clone+0xf7/0x610 kernel/fork.c:2684<br /> [] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd