Linux Linux Kernel version 5.15 : Security vulnerabilities, CVEs (2024)

In the Linux kernel, the following vulnerability has been resolved:Bluetooth: HCI: Remove HCI_AMP supportSince BT_HS has been remove HCI_AMP controllers no longer has any use soremove it along with the capability of creating AMP controllers.Since we no longer need to differentiate between AMP and Primarycontrollers, as only HCI_PRIMARY is left, this also removehdev->dev_type altogether.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member "uzonesize" of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member "media_initialized" to struct alauda_info.- Change a condition in alauda_check_media() to ensure the first initialization.- Add an error check for the return value of alauda_init_media().

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:net: sched: sch_multiq: fix possible OOB write in multiq_tune()q->bands will be assigned to qopt->bands to execute subsequent code logicafter kmalloc. So the old q->bands should not be used in kmalloc.Otherwise, an out-of-bounds write will occur.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Do not use WARN when encode failsWhen asn1_encode_sequence() fails, WARN is not the correct solution.1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c).2. Location is known, which makes the stack trace useless.3. Results a crash if panic_on_warn is set.It is also noteworthy that the use of WARN is undocumented, and itshould be avoided unless there is a carefully considered rationale touse it.Replace WARN with pr_err, and print the return value instead, which isonly useful piece of information.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAPIf one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,taprio_parse_mqprio_opt() must validate it, or userspacecan inject arbitrary data to the kernel, the second timetaprio_change() is called.First call (with valid attributes) sets dev->num_tcto a non zero value.Second call (with arbitrary mqprio attributes)returns early from taprio_parse_mqprio_opt()and bad things can happen.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock.Billy Jheng Bing-Jhong reported a race between __unix_gc() andqueue_oob().__unix_gc() tries to garbage-collect close()d inflight sockets,and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GCwill drop the reference and set NULL to it locklessly.However, the peer socket still can send MSG_OOB message andqueue_oob() can update unix_sk(sk)->oob_skb concurrently, leadingNULL pointer dereference. [0]To fix the issue, let's update unix_sk(sk)->oob_skb under thesk_receive_queue's lock and take it everywhere we touch oob_skb.Note that we defer kfree_skb() in manage_oob() to silence lockdepfalse-positive (See [1]).[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present pagePGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0Oops: 0002 [#1] PREEMPT SMP PTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: events delayed_fputRIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847)Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc ccRSP: 0018:ffffc900001bfd48 EFLAGS: 00000002RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0PKRU: 55555554Call Trace: <TASK> unix_release_sock (net/unix/af_unix.c:654) unix_release (net/unix/af_unix.c:1050) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:423) delayed_fput (fs/file_table.c:444 (discriminator 3)) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) </TASK>Modules linked in:CR2: 0000000000000008

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:net: fix __dst_negative_advice() race__dst_negative_advice() does not enforce proper RCU rules whensk->dst_cache must be cleared, leading to possible UAF.RCU rules are that we must first clear sk->sk_dst_cache,then call dst_release(old_dst).Note that sk_dst_reset(sk) is implementing this protocol correctly,while __dst_negative_advice() uses the wrong order.Given that ip6_negative_advice() has special logicagainst RTF_CACHE, this means each of the three ->negative_advice()existing methods must perform the sk_dst_reset() themselves.Note the check against NULL dst is centralized in__dst_negative_advice(), there is no need to duplicateit in various callbacks.Many thanks to Clement Lecigne for tracking this issue.This old bug became visible after the blamed commit, using UDP sockets.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix division by zero in setup_dsc_configWhen slice_height is 0, the division by slice_height in the calculationof the number of slices will cause a division by zero driver crash. Thisleaves the kernel in a state that requires a reboot. This patch adds acheck to avoid the division by zero.The stack trace below is for the 6.8.4 Kernel. I reproduced the issue ona Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitorconnected via Thunderbolt. The amdgpu driver crashed with this exceptionwhen I rebooted the system with the monitor connected.kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpuAfter applying this patch, the driver no longer crashes when the monitoris connected and the system is rebooted. I believe this is the sameissue reported for 3113.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:erofs: reliably distinguish block based and fscache modeWhen erofs_kill_sb() is called in block dev based mode, s_bdev may nothave been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled,it will be mistaken for fscache mode, and then attempt to free an anon_devthat has never been allocated, triggering the following warning:============================================ida_free called for id=0 which is not allocated.WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140Modules linked in:CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630RIP: 0010:ida_free+0x134/0x140Call Trace: <TASK> erofs_kill_sb+0x81/0x90 deactivate_locked_super+0x35/0x80 get_tree_bdev+0x136/0x1e0 vfs_get_tree+0x2c/0xf0 do_new_mount+0x190/0x2f0 [...]============================================Now when erofs_kill_sb() is called, erofs_sb_info must have beeninitialised, so use sbi->fsid to distinguish between the two modes.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:remoteproc: mediatek: Make sure IPI buffer fits in L2TCMThe IPI buffer location is read from the firmware that we load to theSystem Companion Processor, and it's not granted that both the SRAM(L2TCM) size that is defined in the devicetree node is large enoughfor that, and while this is especially true for multi-core SCP, it'sstill useful to check on single-core variants as well.Failing to perform this check may make this driver perform R/Woperations out of the L2TCM boundary, resulting (at best) in akernel panic.To fix that, check that the IPI buffer fits, otherwise return afailure and refuse to boot the relevant SCP core (or the SCP atall, if this is single core).

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:fs/9p: only translate RWX permissions for plain 9P2000Garbage in plain 9P2000's perm bits is allowed through, which causes itto be able to set (among others) the suid bit. This was presumably notthe intent since the unix extended bits are handled explicitly andconditionally on .u.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()If we fail to allocate propname buffer, we need to drop the referencecount we just took. Because the pinctrl_dt_free_maps() includes thedroping operation, here we call it directly.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()The documentation for device_get_named_child_node() mentions thisimportant point:"The caller is responsible for calling fwnode_handle_put() on thereturned fwnode pointer."Add fwnode_handle_put() to avoid a leaked reference.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn't free the skb when it fails, so move'*buf = NULL' after __skb_linearize(), so that the skb can befreed on the err path.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()vgic_v2_parse_attr() is responsible for finding the vCPU that matchesthe user-provided CPUID, which (of course) may not be valid. If the IDis invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handledgracefully.Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()actually returns something and fail the ioctl if not.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV's transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric. This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject. This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:firewire: ohci: mask bus reset interrupts between ISR and bottom halfIn the FireWire OHCI interrupt handler, if a bus reset interrupt hasoccurred, mask bus reset interrupts until bus_reset_work has serviced andcleared the interrupt.Normally, we always leave bus reset interrupts masked. We infer the busreset from the self-ID interrupt that happens shortly thereafter. Ascenario where we unmask bus reset interrupts was introduced in 2008 ina007bb857e0b26f5d8b73c2ff90782d9c0972620: IfOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, wewill unmask bus reset interrupts so we can log them.irq_handler logs the bus reset interrupt. However, we can't clear the busreset event flag in irq_handler, because we won't service the event untillater. irq_handler exits with the event flag still set. If thecorresponding interrupt is still unmasked, the first bus reset willusually freeze the system due to irq_handler being called again eachtime it exits. This freeze can be reproduced by loading firewire_ohciwith "modprobe firewire_ohci debug=-1" (to enable all debugging output).Apparently there are also some cases where bus_reset_work will get calledsoon enough to clear the event, and operation will continue normally.This freeze was first reported a few months after a007bb85 was committed,but until now it was never fixed. The debug level could safely be setto -1 through sysfs after the module was loaded, but this would beineffectual in logging bus reset interrupts since they were onlyunmasked during initialization.irq_handler will now leave the event flag set but mask bus resetinterrupts, so irq_handler won't be called again and there will be nofreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work willunmask the interrupt after servicing the event, so future interruptswill be caught as desired.As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now beenabled through sysfs in addition to during initial module loading.However, when enabled through sysfs, logging of bus reset interrupts willbe effective only starting with the second bus reset, afterbus_reset_work has executed.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: sync all devices to wait all processes being evictedIf there are more than one device doing reset in parallel, the firstdevice will call kfd_suspend_all_processes() to evict all processeson all devices, this call takes time to finish. other device willstart reset and recover without waiting. if the process has not beenevicted before doing recover, it will be restored, then caused pagefault.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:drm/xe/xe_migrate: Cast to output precision before multiplying operandsAddressing potential overflow in result of multiplication of two lowerprecision (u32) operands before widening it to higher precision(u64).-v2Fix commit message and description. (Rodrigo)(cherry picked from commit 34820967ae7b45411f8f4f737c2d63b0c608e0d7)

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:qibfs: fix dentry leaksimple_recursive_removal() drops the pinning references to all positivesin subtree. For the cases when its argument has been kept alive bythe pinning alone that's exactly the right thing to do, but herethe argument comes from dcache lookup, that needs to be balanced byexplicit dput().f*cked-up-by: Al Viro <viro@zeniv.linux.org.uk>

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:phonet: fix rtm_phonet_notify() skb allocationfill_route() stores three components in the skb:- struct rtmsg- RTA_DST (u8)- RTA_OIF (u32)Therefore, rtm_phonet_notify() should useNLMSG_ALIGN(sizeof(struct rtmsg)) +nla_total_size(1) +nla_total_size(4)

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don't free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.

Source: Linux

In the Linux kernel, the following vulnerability has been resolved:nfs: Handle error of rpc_proc_register() in nfs_net_init().syzkaller reported a warning [0] triggered while destroying immaturenetns.rpc_proc_register() was called in init_nfs_fs(), but its errorhas been ignored since at least the initial commit 1da177e4c3f4("Linux-2.6.12-rc2").Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfsin net namespaces") converted the procfs to per-netns and madethe problem more visible.Even when rpc_proc_register() fails, nfs_net_init() could succeed,and thus nfs_net_exit() will be called while destroying the netns.Then, remove_proc_entry() will be called for non-existing procdirectory and trigger the warning below.Let's handle the error of rpc_proc_register() properly in nfs_net_init().[0]:name 'nfs'WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Modules linked in:CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 ebRSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503cRDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffcR13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: <TASK> rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4eRIP: 0033:0x7f30d0febe5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>

Source: Linux