Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Fix out-of-bound bugs caused by unset skb-&gt;mac_header<br /> <br /> If an AF_PACKET socket is used to send packets through ipvlan and the<br /> default xmit function of the AF_PACKET socket is changed from<br /> dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option<br /> name of PACKET_QDISC_BYPASS, the skb-&gt;mac_header may not be reset and<br /> remains as the initial value of 65535, this may trigger slab-out-of-bounds<br /> bugs as following:<br /> <br /> =================================================================<br /> UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]<br /> PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6<br /> ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33<br /> all Trace:<br /> print_address_description.constprop.0+0x1d/0x160<br /> print_report.cold+0x4f/0x112<br /> kasan_report+0xa3/0x130<br /> ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]<br /> ipvlan_start_xmit+0x29/0xa0 [ipvlan]<br /> __dev_direct_xmit+0x2e2/0x380<br /> packet_direct_xmit+0x22/0x60<br /> packet_snd+0x7c9/0xc40<br /> sock_sendmsg+0x9a/0xa0<br /> __sys_sendto+0x18a/0x230<br /> __x64_sys_sendto+0x74/0x90<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The root cause is:<br /> 1. packet_snd() only reset skb-&gt;mac_header when sock-&gt;type is SOCK_RAW<br /> and skb-&gt;protocol is not specified as in packet_parse_headers()<br /> <br /> 2. packet_direct_xmit() doesn&amp;#39;t reset skb-&gt;mac_header as dev_queue_xmit()<br /> <br /> In this case, skb-&gt;mac_header is 65535 when ipvlan_xmit_mode_l2() is<br /> called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which<br /> use "skb-&gt;head + skb-&gt;mac_header", out-of-bound access occurs.<br /> <br /> This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()<br /> and reset mac header in multicast to solve this out-of-bound bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix crash by keep old cfg when update TCs more than queues<br /> <br /> There are problems if allocated queues less than Traffic Classes.<br /> <br /> Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config<br /> for DCB") already disallow setting less queues than TCs.<br /> <br /> Another case is if we first set less queues, and later update more TCs<br /> config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty<br /> num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.<br /> <br /> [ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.<br /> [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!<br /> [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0<br /> [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI<br /> [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1<br /> [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021<br /> [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60<br /> [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c<br /> [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206<br /> [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0<br /> [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200<br /> [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000<br /> [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100<br /> [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460<br /> [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000<br /> [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0<br /> [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 95.971530] PKRU: 55555554<br /> [ 95.971573] Call Trace:<br /> [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]<br /> [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]<br /> [ 95.971774] ice_vsi_open+0x25/0x120 [ice]<br /> [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]<br /> [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]<br /> [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]<br /> [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]<br /> [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]<br /> [ 95.972220] dcbnl_ieee_set+0x89/0x230<br /> [ 95.972279] ? dcbnl_ieee_del+0x150/0x150<br /> [ 95.972341] dcb_doit+0x124/0x1b0<br /> [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0<br /> [ 95.972457] ? dcb_doit+0x14d/0x1b0<br /> [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280<br /> [ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100<br /> [ 95.972661] netlink_rcv_skb+0xcf/0xf0<br /> [ 95.972720] netlink_unicast+0x16d/0x220<br /> [ 95.972781] netlink_sendmsg+0x2ba/0x3a0<br /> [ 95.975891] sock_sendmsg+0x4c/0x50<br /> [ 95.979032] ___sys_sendmsg+0x2e4/0x300<br /> [ 95.982147] ? kmem_cache_alloc+0x13e/0x190<br /> [ 95.985242] ? __wake_up_common_lock+0x79/0x90<br /> [ 95.988338] ? __check_object_size+0xac/0x1b0<br /> [ 95.991440] ? _copy_to_user+0x22/0x30<br /> [ 95.994539] ? move_addr_to_user+0xbb/0xd0<br /> [ 95.997619] ? __sys_sendmsg+0x53/0x80<br /> [ 96.000664] __sys_sendmsg+0x53/0x80<br /> [ 96.003747] do_syscall_64+0x5b/0x1d0<br /> [ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> Only update num_txq/rxq when passed check, and restore tc_cfg if setup<br /> queue map failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Don&amp;#39;t double unplug aux on peer initiated reset<br /> <br /> In the IDC callback that is accessed when the aux drivers request a reset,<br /> the function to unplug the aux devices is called. This function is also<br /> called in the ice_prepare_for_reset function. This double call is causing<br /> a "scheduling while atomic" BUG.<br /> <br /> [ 662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003<br /> <br /> [ 662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003<br /> <br /> [ 662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003<br /> <br /> [ 662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424<br /> <br /> [ 662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset<br /> <br /> [ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002<br /> <br /> [ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002<br /> [ 662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe<br /> r ttm<br /> [ 662.815546] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse<br /> [ 662.815557] Preemption disabled at:<br /> [ 662.815558] [] 0x0<br /> [ 662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S OE 5.17.1 #2<br /> [ 662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021<br /> [ 662.815568] Call Trace:<br /> [ 662.815572] <br /> [ 662.815574] dump_stack_lvl+0x33/0x42<br /> [ 662.815581] __schedule_bug.cold.147+0x7d/0x8a<br /> [ 662.815588] __schedule+0x798/0x990<br /> [ 662.815595] schedule+0x44/0xc0<br /> [ 662.815597] schedule_preempt_disabled+0x14/0x20<br /> [ 662.815600] __mutex_lock.isra.11+0x46c/0x490<br /> [ 662.815603] ? __ibdev_printk+0x76/0xc0 [ib_core]<br /> [ 662.815633] device_del+0x37/0x3d0<br /> [ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice]<br /> [ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice]<br /> [ 662.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]<br /> [ 662.815712] ? bitmap_find_next_zero_area_off+0x45/0xa0<br /> [ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice]<br /> [ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice]<br /> [ 662.815756] __handle_irq_event_percpu+0x4c/0x180<br /> [ 662.815762] handle_irq_event_percpu+0xf/0x40<br /> [ 662.815764] handle_irq_event+0x34/0x60<br /> [ 662.815766] handle_edge_irq+0x9a/0x1c0<br /> [ 662.815770] __common_interrupt+0x62/0x100<br /> [ 662.815774] common_interrupt+0xb4/0xd0<br /> [ 662.815779] <br /> [ 662.815780] <br /> [ 662.815780] asm_common_interrupt+0x1e/0x40<br /> [ 662.815785] RIP: 0010:cpuidle_enter_state+0xd6/0x380<br /> [ 662.815789] Code: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 00 31 ff e8 ae c5 9c ff fb 45 85 f6 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49<br /> [ 662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 00000202<br /> [ 662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX: 000000000000001f<br /> [ 662.815795] RDX: 0000009a52da2d08 R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()<br /> <br /> nf_osf_find() incorrectly returns true on mismatch, this leads to<br /> copying uninitialized memory area in nft_osf which can be used to leak<br /> stale kernel stack data to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Harden accesses to the reset domains<br /> <br /> Accessing reset domains descriptors by the index upon the SCMI drivers<br /> requests through the SCMI reset operations interface can potentially<br /> lead to out-of-bound violations if the SCMI driver misbehave.<br /> <br /> Add an internal consistency check before any such domains descriptors<br /> accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()<br /> <br /> We should call of_node_put() for the reference returned by<br /> of_parse_phandle() in fail path or when it is not used anymore.<br /> Here we only need to move the of_node_put() before the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: topology: fix possible overflow in amu_fie_setup()<br /> <br /> cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,<br /> while freq_inv_set_max_ratio() gets passed this frequency in Hz as &amp;#39;u64&amp;#39;.<br /> Multiplying max frequency by 1000 can potentially result in overflow --<br /> multiplying by 1000ULL instead should avoid that...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.<br /> <br /> Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations<br /> __free_slab() invocations out of IRQ context") moved all flush_cpu_slab()<br /> invocations to the global workqueue to avoid a problem related<br /> with deactivate_slab()/__free_slab() being called from an IRQ context<br /> on PREEMPT_RT kernels.<br /> <br /> When the flush_all_cpu_locked() function is called from a task context<br /> it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up<br /> flushing the global workqueue, this will cause a dependency issue.<br /> <br /> workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]<br /> is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab<br /> WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637<br /> check_flush_dependency+0x10a/0x120<br /> Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]<br /> RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:<br /> __flush_work.isra.0+0xbf/0x220<br /> ? __queue_work+0x1dc/0x420<br /> flush_all_cpus_locked+0xfb/0x120<br /> __kmem_cache_shutdown+0x2b/0x320<br /> kmem_cache_destroy+0x49/0x100<br /> bioset_exit+0x143/0x190<br /> blk_release_queue+0xb9/0x100<br /> kobject_cleanup+0x37/0x130<br /> nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]<br /> nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]<br /> <br /> Fix this bug by creating a workqueue for the flush operation with<br /> the WQ_MEM_RECLAIM bit set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: fix to return errno if kmalloc() fails<br /> <br /> In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to<br /> out-of-memory, if it fails, return errno correctly rather than<br /> triggering panic via BUG_ON();<br /> <br /> kernel BUG at mm/slub.c:5893!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> <br /> Call trace:<br /> sysfs_slab_add+0x258/0x260 mm/slub.c:5973<br /> __kmem_cache_create+0x60/0x118 mm/slub.c:4899<br /> create_cache mm/slab_common.c:229 [inline]<br /> kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335<br /> kmem_cache_create+0x1c/0x28 mm/slab_common.c:390<br /> f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]<br /> f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808<br /> f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149<br /> mount_bdev+0x1b8/0x210 fs/super.c:1400<br /> f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512<br /> legacy_get_tree+0x30/0x74 fs/fs_context.c:610<br /> vfs_get_tree+0x40/0x140 fs/super.c:1530<br /> do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040<br /> path_mount+0x358/0x914 fs/namespace.c:3370<br /> do_mount fs/namespace.c:3383 [inline]<br /> __do_sys_mount fs/namespace.c:3591 [inline]<br /> __se_sys_mount fs/namespace.c:3568 [inline]<br /> __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully<br /> <br /> When running gpio test on nxp-ls1028 platform with below command<br /> gpiomon --num-events=3 --rising-edge gpiochip1 25<br /> There will be a warning trace as below:<br /> Call trace:<br /> free_irq+0x204/0x360<br /> lineevent_free+0x64/0x70<br /> gpio_ioctl+0x598/0x6a0<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x5c/0x130<br /> ......<br /> el0t_64_sync+0x1a0/0x1a4<br /> The reason of this issue is that calling request_threaded_irq()<br /> function failed, and then lineevent_free() is invoked to release<br /> the resource. Since the lineevent_state::irq was already set, so<br /> the subsequent invocation of free_irq() would trigger the above<br /> warning call trace. To fix this issue, set the lineevent_state::irq<br /> after the IRQ register successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mockup: Fix potential resource leakage when register a chip<br /> <br /> If creation of software node fails, the locally allocated string<br /> array is left unfreed. Free it on error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Really move i915_gem_context.link under ref protection<br /> <br /> i915_perf assumes that it can use the i915_gem_context reference to<br /> protect its i915-&gt;gem.contexts.list iteration. However, this requires<br /> that we do not remove the context from the list until after we drop the<br /> final reference and release the struct. If, as currently, we remove the<br /> context from the list during context_close(), the link.next pointer may<br /> be poisoned while we are holding the context reference and cause a GPF:<br /> <br /> [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff<br /> [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP<br /> [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180<br /> [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017<br /> [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]<br /> [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff<br /> [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202<br /> [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68<br /> [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc<br /> [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860<br /> [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc<br /> [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000<br /> [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0<br /> [ 4070.575029] Call Trace:<br /> [ 4070.575033] <br /> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]<br /> [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]<br /> [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]<br /> [ 4070.575224] ? asm_common_interrupt+0x1e/0x40<br /> [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]<br /> [ 4070.575290] drm_ioctl_kernel+0x85/0x110<br /> [ 4070.575296] ? update_load_avg+0x5f/0x5e0<br /> [ 4070.575302] drm_ioctl+0x1d3/0x370<br /> [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]<br /> [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]<br /> [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0<br /> [ 4070.575451] ? __do_softirq+0xaa/0x1d2<br /> [ 4070.575456] do_syscall_64+0x35/0x80<br /> [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 4070.575467] RIP: 0033:0x7f1ed5c10397<br /> [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48<br /> [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397<br /> [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006<br /> [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005<br /> [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a<br /> [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0<br /> [ 4070.575505] <br /> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus<br /> ---truncated---