Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix memory leak in netlbl_cipsov4_add_std<br /> <br /> Reported by syzkaller:<br /> BUG: memory leak<br /> unreferenced object 0xffff888105df7000 (size 64):<br /> comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)<br /> hex dump (first 32 bytes):<br /> 00 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 /> [] kmalloc include/linux/slab.h:590 [inline]<br /> [] kzalloc include/linux/slab.h:720 [inline]<br /> [] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]<br /> [] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416<br /> [] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739<br /> [] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]<br /> [] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800<br /> [] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504<br /> [] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]<br /> [] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340<br /> [] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929<br /> [] sock_sendmsg_nosec net/socket.c:654 [inline]<br /> [] sock_sendmsg+0x139/0x170 net/socket.c:674<br /> [] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350<br /> [] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404<br /> [] __sys_sendmsg+0xd3/0x190 net/socket.c:2433<br /> [] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The memory of doi_def-&gt;map.std pointing is allocated in<br /> netlbl_cipsov4_add_std, but no place has freed it. It should be<br /> freed in cipso_v4_doi_free which frees the cipso DOI resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix use-after-free of encap entry in neigh update handler<br /> <br /> Function mlx5e_rep_neigh_update() wasn&amp;#39;t updated to accommodate rtnl lock<br /> removal from TC filter update path and properly handle concurrent encap<br /> entry insertion/deletion which can lead to following use-after-free:<br /> <br /> [23827.464923] ==================================================================<br /> [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635<br /> [23827.472251]<br /> [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5<br /> [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]<br /> [23827.476731] Call Trace:<br /> [23827.477260] dump_stack+0xbb/0x107<br /> [23827.477906] print_address_description.constprop.0+0x18/0x140<br /> [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.480905] kasan_report.cold+0x7c/0xd8<br /> [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.482744] kasan_check_range+0x145/0x1a0<br /> [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]<br /> [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]<br /> [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]<br /> [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]<br /> [23827.497486] ? read_word_at_a_time+0xe/0x20<br /> [23827.498250] ? strscpy+0xa0/0x2a0<br /> [23827.498889] process_one_work+0x8ac/0x14e0<br /> [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0<br /> [23827.501359] ? rwlock_bug.part.0+0x90/0x90<br /> [23827.502116] worker_thread+0x53b/0x1220<br /> [23827.502831] ? process_one_work+0x14e0/0x14e0<br /> [23827.503627] kthread+0x328/0x3f0<br /> [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40<br /> [23827.505065] ? __kthread_bind_mask+0x90/0x90<br /> [23827.505912] ret_from_fork+0x1f/0x30<br /> [23827.506621]<br /> [23827.506987] Allocated by task 28248:<br /> [23827.507694] kasan_save_stack+0x1b/0x40<br /> [23827.508476] __kasan_kmalloc+0x7c/0x90<br /> [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]<br /> [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]<br /> [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]<br /> [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]<br /> [23827.513298] tc_setup_cb_add+0x1d5/0x420<br /> [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]<br /> [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]<br /> [23827.515821] tc_new_tfilter+0x89a/0x2070<br /> [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0<br /> [23827.517300] netlink_rcv_skb+0x11d/0x340<br /> [23827.518021] netlink_unicast+0x42b/0x700<br /> [23827.518742] netlink_sendmsg+0x743/0xc20<br /> [23827.519467] sock_sendmsg+0xb2/0xe0<br /> [23827.520131] ____sys_sendmsg+0x590/0x770<br /> [23827.520851] ___sys_sendmsg+0xd8/0x160<br /> [23827.521552] __sys_sendmsg+0xb7/0x140<br /> [23827.522238] do_syscall_64+0x3a/0x70<br /> [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [23827.523797]<br /> [23827.524163] Freed by task 25948:<br /> [23827.524780] kasan_save_stack+0x1b/0x40<br /> [23827.525488] kasan_set_track+0x1c/0x30<br /> [23827.526187] kasan_set_free_info+0x20/0x30<br /> [23827.526968] __kasan_slab_free+0xed/0x130<br /> [23827.527709] slab_free_freelist_hook+0xcf/0x1d0<br /> [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0<br /> [23827.529317] kfree_rcu_work+0x55f/0xb70<br /> [23827.530024] process_one_work+0x8ac/0x14e0<br /> [23827.530770] worker_thread+0x53b/0x1220<br /> [23827.531480] kthread+0x328/0x3f0<br /> [23827.532114] ret_from_fork+0x1f/0x30<br /> [23827.532785]<br /> [23827.533147] Last potentially related work creation:<br /> [23827.534007] kasan_save_stack+0x1b/0x40<br /> [23827.534710] kasan_record_aux_stack+0xab/0xc0<br /> [23827.535492] kvfree_call_rcu+0x31/0x7b0<br /> [23827.536206] mlx5e_tc_del<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ioremap: Map EFI-reserved memory as encrypted for SEV<br /> <br /> Some drivers require memory that is marked as EFI boot services<br /> data. In order for this memory to not be re-used by the kernel<br /> after ExitBootServices(), efi_mem_reserve() is used to preserve it<br /> by inserting a new EFI memory descriptor and marking it with the<br /> EFI_MEMORY_RUNTIME attribute.<br /> <br /> Under SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to<br /> be mapped encrypted by Linux, otherwise the kernel might crash at boot<br /> like below:<br /> <br /> EFI Variables Facility v0.08 2004-May-17<br /> general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI<br /> CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:efi_mokvar_entry_next<br /> [...]<br /> Call Trace:<br /> efi_mokvar_sysfs_init<br /> ? efi_mokvar_table_init<br /> do_one_initcall<br /> ? __kmalloc<br /> kernel_init_freeable<br /> ? rest_init<br /> kernel_init<br /> ret_from_fork<br /> <br /> Expand the __ioremap_check_other() function to additionally check for<br /> this other type of boot data reserved at runtime and indicate that it<br /> should be mapped encrypted for an SEV guest.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: aardvark: Fix kernel panic during PIO transfer<br /> <br /> Trying to start a new PIO transfer by writing value 0 in PIO_START register<br /> when previous transfer has not yet completed (which is indicated by value 1<br /> in PIO_START) causes an External Abort on CPU, which results in kernel<br /> panic:<br /> <br /> SError Interrupt on CPU0, code 0xbf000002 -- SError<br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> <br /> To prevent kernel panic, it is required to reject a new PIO transfer when<br /> previous one has not finished yet.<br /> <br /> If previous PIO transfer is not finished yet, the kernel may issue a new<br /> PIO request only if the previous PIO transfer timed out.<br /> <br /> In the past the root cause of this issue was incorrectly identified (as it<br /> often happens during link retraining or after link down event) and special<br /> hack was implemented in Trusted Firmware to catch all SError events in EL3,<br /> to ignore errors with code 0xbf000002 and not forwarding any other errors<br /> to kernel and instead throw panic from EL3 Trusted Firmware handler.<br /> <br /> Links to discussion and patches about this issue:<br /> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50<br /> https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/<br /> https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/<br /> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541<br /> <br /> But the real cause was the fact that during link retraining or after link<br /> down event the PIO transfer may take longer time, up to the 1.44s until it<br /> times out. This increased probability that a new PIO transfer would be<br /> issued by kernel while previous one has not finished yet.<br /> <br /> After applying this change into the kernel, it is possible to revert the<br /> mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Immediately reset the MMU context when the SMM flag is cleared<br /> <br /> Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so<br /> that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s<br /> flag. If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail<br /> without calling post_leave_smm() and leave the MMU in a bad state.<br /> <br /> The bad MMU role can lead to a NULL pointer dereference when grabbing a<br /> shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn<br /> will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will<br /> use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1). SMM has<br /> an entirely different set of memslots, and so the initial lookup can find<br /> a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]<br /> RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947<br /> Code: 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44<br /> RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002<br /> R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000<br /> R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000<br /> FS: 000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline]<br /> mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604<br /> __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline]<br /> direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769<br /> kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline]<br /> kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065<br /> vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122<br /> vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428<br /> vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494<br /> kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722<br /> kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:1069 [inline]<br /> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055<br /> do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x440ce9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcba_usb: fix memory leak in mcba_usb<br /> <br /> Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS<br /> Analyzer Tool. The problem was in unfreed usb_coherent.<br /> <br /> In mcba_usb_start() 20 coherent buffers are allocated and there is<br /> nothing, that frees them:<br /> <br /> 1) In callback function the urb is resubmitted and that&amp;#39;s all<br /> 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER<br /> is not set (see mcba_usb_start) and this flag cannot be used with<br /> coherent buffers.<br /> <br /> Fail log:<br /> | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected<br /> | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)<br /> <br /> So, all allocated buffers should be freed with usb_free_coherent()<br /> explicitly<br /> <br /> NOTE:<br /> The same pattern for allocating and freeing coherent buffers<br /> is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: fix Use-after-Free, hold skb ref while in use<br /> <br /> This patch fixes a Use-after-Free found by the syzbot.<br /> <br /> The problem is that a skb is taken from the per-session skb queue,<br /> without incrementing the ref count. This leads to a Use-after-Free if<br /> the skb is taken concurrently from the session queue due to a CTS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: rt4801: Fix NULL pointer dereference if priv-&gt;enable_gpios is NULL<br /> <br /> devm_gpiod_get_array_optional may return NULL if no GPIO was assigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()<br /> <br /> Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix<br /> some resource leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: fix potential use-after-free in ec_bhf_remove<br /> <br /> static void ec_bhf_remove(struct pci_dev *dev)<br /> {<br /> ...<br /> struct ec_bhf_priv *priv = netdev_priv(net_dev);<br /> <br /> unregister_netdev(net_dev);<br /> free_netdev(net_dev);<br /> <br /> pci_iounmap(dev, priv-&gt;dma_io);<br /> pci_iounmap(dev, priv-&gt;io);<br /> ...<br /> }<br /> <br /> priv is netdev private data, but it is used<br /> after free_netdev(). It can cause use-after-free when accessing priv<br /> pointer. So, fix it by moving free_netdev() after pci_iounmap()<br /> calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cdc_eem: fix tx fixup skb leak<br /> <br /> when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),<br /> if skb_copy_expand() failed, it return NULL,<br /> usbnet_start_xmit() will have no chance to free original skb.<br /> <br /> fix it by free orginal skb in eem_tx_fixup() first,<br /> then check skb clone status, if failed, return NULL to usbnet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hamradio: fix memory leak in mkiss_close<br /> <br /> My local syzbot instance hit memory leak in<br /> mkiss_open()[1]. The problem was in missing<br /> free_netdev() in mkiss_close().<br /> <br /> In mkiss_open() netdevice is allocated and then<br /> registered, but in mkiss_close() netdevice was<br /> only unregistered, but not freed.<br /> <br /> Fail log:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880281ba000 (size 4096):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............<br /> 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .&amp;#39;.*............<br /> backtrace:<br /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x98/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880141a9a00 (size 96):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....<br /> 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........<br /> backtrace:<br /> [] __hw_addr_create_ex+0x5b/0x310<br /> [] __hw_addr_add_ex+0x1f8/0x2b0<br /> [] dev_addr_init+0x10b/0x1f0<br /> [] alloc_netdev_mqs+0x13b/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880219bfc00 (size 512):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............<br /> 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x777/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888029b2b200 (size 256):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 00 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 /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x912/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae