Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix use-after-free on failed backlog decryption<br /> <br /> When the decrypt request goes to the backlog and crypto_aead_decrypt<br /> returns -EBUSY, tls_do_decryption will wait until all async<br /> decryptions have completed. If one of them fails, tls_do_decryption<br /> will return -EBADMSG and tls_decrypt_sg jumps to the error path,<br /> releasing all the pages. But the pages have been passed to the async<br /> callback, and have already been released by tls_decrypt_done.<br /> <br /> The only true async case is when crypto_aead_decrypt returns<br /> -EINPROGRESS. With -EBUSY, we already waited so we can tell<br /> tls_sw_recvmsg that the data is available for immediate copy, but we<br /> need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the<br /> memory has already been released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix double-free on socket dismantle<br /> <br /> when MPTCP server accepts an incoming connection, it clones its listener<br /> socket. However, the pointer to &amp;#39;inet_opt&amp;#39; for the new socket has the same<br /> value as the original one: as a consequence, on program exit it&amp;#39;s possible<br /> to observe the following splat:<br /> <br /> BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0<br /> Free of addr ffff888485950880 by task swapper/25/0<br /> <br /> CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609<br /> Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> print_report+0xca/0x620<br /> kasan_report_invalid_free+0x64/0x90<br /> __kasan_slab_free+0x1aa/0x1f0<br /> kfree+0xed/0x2e0<br /> inet_sock_destruct+0x54f/0x8b0<br /> __sk_destruct+0x48/0x5b0<br /> rcu_do_batch+0x34e/0xd90<br /> rcu_core+0x559/0xac0<br /> __do_softirq+0x183/0x5a4<br /> irq_exit_rcu+0x12d/0x170<br /> sysvec_apic_timer_interrupt+0x6b/0x80<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> RIP: 0010:cpuidle_enter_state+0x175/0x300<br /> Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b<br /> RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000<br /> RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588<br /> RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080<br /> R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0<br /> R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80<br /> cpuidle_enter+0x4a/0xa0<br /> do_idle+0x310/0x410<br /> cpu_startup_entry+0x51/0x60<br /> start_secondary+0x211/0x270<br /> secondary_startup_64_no_verify+0x184/0x18b<br /> <br /> <br /> Allocated by task 6853:<br /> kasan_save_stack+0x1c/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0xa6/0xb0<br /> __kmalloc+0x1eb/0x450<br /> cipso_v4_sock_setattr+0x96/0x360<br /> netlbl_sock_setattr+0x132/0x1f0<br /> selinux_netlbl_socket_post_create+0x6c/0x110<br /> selinux_socket_post_create+0x37b/0x7f0<br /> security_socket_post_create+0x63/0xb0<br /> __sock_create+0x305/0x450<br /> __sys_socket_create.part.23+0xbd/0x130<br /> __sys_socket+0x37/0xb0<br /> __x64_sys_socket+0x6f/0xb0<br /> do_syscall_64+0x83/0x160<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Freed by task 6858:<br /> kasan_save_stack+0x1c/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x12c/0x1f0<br /> kfree+0xed/0x2e0<br /> inet_sock_destruct+0x54f/0x8b0<br /> __sk_destruct+0x48/0x5b0<br /> subflow_ulp_release+0x1f0/0x250<br /> tcp_cleanup_ulp+0x6e/0x110<br /> tcp_v4_destroy_sock+0x5a/0x3a0<br /> inet_csk_destroy_sock+0x135/0x390<br /> tcp_fin+0x416/0x5c0<br /> tcp_data_queue+0x1bc8/0x4310<br /> tcp_rcv_state_process+0x15a3/0x47b0<br /> tcp_v4_do_rcv+0x2c1/0x990<br /> tcp_v4_rcv+0x41fb/0x5ed0<br /> ip_protocol_deliver_rcu+0x6d/0x9f0<br /> ip_local_deliver_finish+0x278/0x360<br /> ip_local_deliver+0x182/0x2c0<br /> ip_rcv+0xb5/0x1c0<br /> __netif_receive_skb_one_core+0x16e/0x1b0<br /> process_backlog+0x1e3/0x650<br /> __napi_poll+0xa6/0x500<br /> net_rx_action+0x740/0xbb0<br /> __do_softirq+0x183/0x5a4<br /> <br /> The buggy address belongs to the object at ffff888485950880<br /> which belongs to the cache kmalloc-64 of size 64<br /> The buggy address is located 0 bytes inside of<br /> 64-byte region [ffff888485950880, ffff8884859508c0)<br /> <br /> The buggy address belongs to the physical page:<br /> page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950<br /> flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)<br /> page_type: 0xffffffff()<br /> raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006<br /> raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888485950780: fa fb fb<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: arm: Fix NULL dereference on scmi_perf_domain removal<br /> <br /> On unloading of the scmi_perf_domain module got the below splat, when in<br /> the DT provided to the system under test the &amp;#39;#power-domain-cells&amp;#39; property<br /> was missing. Indeed, this particular setup causes the probe to bail out<br /> early without giving any error, which leads to the -&gt;remove() callback gets<br /> to run too, but without all the expected initialized structures in place.<br /> <br /> Add a check and bail out early on remove too.<br /> <br /> Call trace:<br /> scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain]<br /> scmi_dev_remove+0x28/0x40 [scmi_core]<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1dc/0x240<br /> driver_detach+0x58/0xa8<br /> bus_remove_driver+0x78/0x108<br /> driver_unregister+0x38/0x70<br /> scmi_driver_unregister+0x28/0x180 [scmi_core]<br /> scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain]<br /> __arm64_sys_delete_module+0x1a8/0x2c0<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x34/0xb8<br /> el0t_64_sync_handler+0x100/0x130<br /> el0t_64_sync+0x190/0x198<br /> Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix protection fault in iommufd_test_syz_conv_iova<br /> <br /> Syzkaller reported the following bug:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7]<br /> Call Trace:<br /> lock_acquire<br /> lock_acquire+0x1ce/0x4f0<br /> down_read+0x93/0x4a0<br /> iommufd_test_syz_conv_iova+0x56/0x1f0<br /> iommufd_test_access_rw.isra.0+0x2ec/0x390<br /> iommufd_test+0x1058/0x1e30<br /> iommufd_fops_ioctl+0x381/0x510<br /> vfs_ioctl<br /> __do_sys_ioctl<br /> __se_sys_ioctl<br /> __x64_sys_ioctl+0x170/0x1e0<br /> do_syscall_x64<br /> do_syscall_64+0x71/0x140<br /> <br /> This is because the new iommufd_access_change_ioas() sets access-&gt;ioas to<br /> NULL during its process, so the lock might be gone in a concurrent racing<br /> context.<br /> <br /> Fix this by doing the same access-&gt;ioas sanity as iommufd_access_rw() and<br /> iommufd_access_pin_pages() functions do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix iopt_access_list_id overwrite bug<br /> <br /> Syzkaller reported the following WARN_ON:<br /> WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360<br /> <br /> Call Trace:<br /> iommufd_access_change_ioas+0x2fe/0x4e0<br /> iommufd_access_destroy_object+0x50/0xb0<br /> iommufd_object_remove+0x2a3/0x490<br /> iommufd_object_destroy_user<br /> iommufd_access_destroy+0x71/0xb0<br /> iommufd_test_staccess_release+0x89/0xd0<br /> __fput+0x272/0xb50<br /> __fput_sync+0x4b/0x60<br /> __do_sys_close<br /> __se_sys_close<br /> __x64_sys_close+0x8b/0x110<br /> do_syscall_x64<br /> <br /> The mismatch between the access pointer in the list and the passed-in<br /> pointer is resulting from an overwrite of access-&gt;iopt_access_list_id, in<br /> iopt_add_access(). Called from iommufd_access_change_ioas() when<br /> xa_alloc() succeeds but iopt_calculate_iova_alignment() fails.<br /> <br /> Add a new_id in iopt_add_access() and only update iopt_access_list_id when<br /> returning successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: mmci: stm32: fix DMA API overlapping mappings warning<br /> <br /> Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:<br /> <br /> DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568<br /> add_dma_entry+0x234/0x2f4<br /> Modules linked in:<br /> CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1<br /> Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)<br /> Workqueue: events_freezable mmc_rescan<br /> Call trace:<br /> add_dma_entry+0x234/0x2f4<br /> debug_dma_map_sg+0x198/0x350<br /> __dma_map_sg_attrs+0xa0/0x110<br /> dma_map_sg_attrs+0x10/0x2c<br /> sdmmc_idma_prep_data+0x80/0xc0<br /> mmci_prep_data+0x38/0x84<br /> mmci_start_data+0x108/0x2dc<br /> mmci_request+0xe4/0x190<br /> __mmc_start_request+0x68/0x140<br /> mmc_start_request+0x94/0xc0<br /> mmc_wait_for_req+0x70/0x100<br /> mmc_send_tuning+0x108/0x1ac<br /> sdmmc_execute_tuning+0x14c/0x210<br /> mmc_execute_tuning+0x48/0xec<br /> mmc_sd_init_uhs_card.part.0+0x208/0x464<br /> mmc_sd_init_card+0x318/0x89c<br /> mmc_attach_sd+0xe4/0x180<br /> mmc_rescan+0x244/0x320<br /> <br /> DMA API debug brings to light leaking dma-mappings as dma_map_sg and<br /> dma_unmap_sg are not correctly balanced.<br /> <br /> If an error occurs in mmci_cmd_irq function, only mmci_dma_error<br /> function is called and as this API is not managed on stm32 variant,<br /> dma_unmap_sg is never called in this error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: init irq after reg initialization<br /> <br /> Initialize the qDMA irqs after the registers are configured so that<br /> interrupts that may have been pending from a primary kernel don&amp;#39;t get<br /> processed by the irq handler before it is ready to and cause panic with<br /> the following trace:<br /> <br /> Call trace:<br /> fsl_qdma_queue_handler+0xf8/0x3e8<br /> __handle_irq_event_percpu+0x78/0x2b0<br /> handle_irq_event_percpu+0x1c/0x68<br /> handle_irq_event+0x44/0x78<br /> handle_fasteoi_irq+0xc8/0x178<br /> generic_handle_irq+0x24/0x38<br /> __handle_domain_irq+0x90/0x100<br /> gic_handle_irq+0x5c/0xb8<br /> el1_irq+0xb8/0x180<br /> _raw_spin_unlock_irqrestore+0x14/0x40<br /> __setup_irq+0x4bc/0x798<br /> request_threaded_irq+0xd8/0x190<br /> devm_request_threaded_irq+0x74/0xe8<br /> fsl_qdma_probe+0x4d4/0xca8<br /> platform_drv_probe+0x50/0xa0<br /> really_probe+0xe0/0x3f8<br /> driver_probe_device+0x64/0x130<br /> device_driver_attach+0x6c/0x78<br /> __driver_attach+0xbc/0x158<br /> bus_for_each_dev+0x5c/0x98<br /> driver_attach+0x20/0x28<br /> bus_add_driver+0x158/0x220<br /> driver_register+0x60/0x110<br /> __platform_driver_register+0x44/0x50<br /> fsl_qdma_driver_init+0x18/0x20<br /> do_one_initcall+0x48/0x258<br /> kernel_init_freeable+0x1a4/0x23c<br /> kernel_init+0x10/0xf8<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: arm64/neonbs - fix out-of-bounds access on short input<br /> <br /> The bit-sliced implementation of AES-CTR operates on blocks of 128<br /> bytes, and will fall back to the plain NEON version for tail blocks or<br /> inputs that are shorter than 128 bytes to begin with.<br /> <br /> It will call straight into the plain NEON asm helper, which performs all<br /> memory accesses in granules of 16 bytes (the size of a NEON register).<br /> For this reason, the associated plain NEON glue code will copy inputs<br /> shorter than 16 bytes into a temporary buffer, given that this is a rare<br /> occurrence and it is not worth the effort to work around this in the asm<br /> code.<br /> <br /> The fallback from the bit-sliced NEON version fails to take this into<br /> account, potentially resulting in out-of-bounds accesses. So clone the<br /> same workaround, and use a temp buffer for short in/outputs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read<br /> <br /> There is chip (ls1028a) errata:<br /> <br /> The SoC may hang on 16 byte unaligned read transactions by QDMA.<br /> <br /> Unaligned read transactions initiated by QDMA may stall in the NOC<br /> (Network On-Chip), causing a deadlock condition. Stalled transactions will<br /> trigger completion timeouts in PCIe controller.<br /> <br /> Workaround:<br /> Enable prefetch by setting the source descriptor prefetchable bit<br /> ( SD[PF] = 1 ).<br /> <br /> Implement this workaround.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: dev-replace: properly validate device names<br /> <br /> There&amp;#39;s a syzbot report that device name buffers passed to device<br /> replace are not properly checked for string termination which could lead<br /> to a read out of bounds in getname_kernel().<br /> <br /> Add a helper that validates both source and target device name buffers.<br /> For devid as the source initialize the buffer to empty string in case<br /> something tries to read it later.<br /> <br /> This was originally analyzed and fixed in a different way by Edward Adam<br /> Davis (see links).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free of anonymous device after snapshot creation failure<br /> <br /> When creating a snapshot we may do a double free of an anonymous device<br /> in case there&amp;#39;s an error committing the transaction. The second free may<br /> result in freeing an anonymous device number that was allocated by some<br /> other subsystem in the kernel or another btrfs filesystem.<br /> <br /> The steps that lead to this:<br /> <br /> 1) At ioctl.c:create_snapshot() we allocate an anonymous device number<br /> and assign it to pending_snapshot-&gt;anon_dev;<br /> <br /> 2) Then we call btrfs_commit_transaction() and end up at<br /> transaction.c:create_pending_snapshot();<br /> <br /> 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device<br /> number stored in pending_snapshot-&gt;anon_dev;<br /> <br /> 4) btrfs_get_new_fs_root() frees that anonymous device number because<br /> btrfs_lookup_fs_root() returned a root - someone else did a lookup<br /> of the new root already, which could some task doing backref walking;<br /> <br /> 5) After that some error happens in the transaction commit path, and at<br /> ioctl.c:create_snapshot() we jump to the &amp;#39;fail&amp;#39; label, and after<br /> that we free again the same anonymous device number, which in the<br /> meanwhile may have been reallocated somewhere else, because<br /> pending_snapshot-&gt;anon_dev still has the same value as in step 1.<br /> <br /> Recently syzbot ran into this and reported the following trace:<br /> <br /> ------------[ cut here ]------------<br /> ida_free called for id=51 which is not allocated.<br /> WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525<br /> Modules linked in:<br /> CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525<br /> Code: 10 42 80 3c 28 (...)<br /> RSP: 0018:ffffc90015a67300 EFLAGS: 00010246<br /> RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000<br /> RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000<br /> RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4<br /> R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246<br /> R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246<br /> FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346<br /> create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837<br /> create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931<br /> btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404<br /> create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848<br /> btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998<br /> btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044<br /> __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306<br /> btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393<br /> btrfs_ioctl+0xa74/0xd40<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:871 [inline]<br /> __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7fca3e67dda9<br /> Code: 28 00 00 00 (...)<br /> RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9<br /> RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003<br /> RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658<br /> <br /> <br /> Where we get an explicit message where we attempt to free an anonymous<br /> device number that is not currently allocated. It happens in a different<br /> code path from the example below, at btrfs_get_root_ref(), so this change<br /> may not fix the case triggered by sy<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: fix use-after-free and null-ptr-deref in gtp_newlink()<br /> <br /> The gtp_link_ops operations structure for the subsystem must be<br /> registered after registering the gtp_net_ops pernet operations structure.<br /> <br /> Syzkaller hit &amp;#39;general protection fault in gtp_genl_dump_pdp&amp;#39; bug:<br /> <br /> [ 1010.702740] gtp: GTP module unloaded<br /> [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1<br /> [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014<br /> [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00<br /> [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203<br /> [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000<br /> [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282<br /> [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000<br /> [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80<br /> [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400<br /> [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000<br /> [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0<br /> [ 1010.715968] PKRU: 55555554<br /> [ 1010.715972] Call Trace:<br /> [ 1010.715985] ? __die_body.cold+0x1a/0x1f<br /> [ 1010.715995] ? die_addr+0x43/0x70<br /> [ 1010.716002] ? exc_general_protection+0x199/0x2f0<br /> [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30<br /> [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]<br /> [ 1010.716042] __rtnl_newlink+0x1063/0x1700<br /> [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0<br /> [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0<br /> [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0<br /> [ 1010.716076] ? __kernel_text_address+0x56/0xa0<br /> [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0<br /> [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30<br /> [ 1010.716098] ? arch_stack_walk+0x9e/0xf0<br /> [ 1010.716106] ? stack_trace_save+0x91/0xd0<br /> [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170<br /> [ 1010.716121] ? __lock_acquire+0x15c5/0x5380<br /> [ 1010.716139] ? mark_held_locks+0x9e/0xe0<br /> [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0<br /> [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700<br /> [ 1010.716160] rtnl_newlink+0x69/0xa0<br /> [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50<br /> [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716179] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50<br /> [ 1010.716196] netlink_rcv_skb+0x14d/0x440<br /> [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716208] ? netlink_ack+0xab0/0xab0<br /> [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50<br /> [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50<br /> [ 1010.716226] ? __virt_addr_valid+0x30b/0x590<br /> [ 1010.716233] netlink_unicast+0x54b/0x800<br /> [ 1010.716240] ? netlink_attachskb+0x870/0x870<br /> [ 1010.716248] ? __check_object_size+0x2de/0x3b0<br /> [ 1010.716254] netlink_sendmsg+0x938/0xe40<br /> [ 1010.716261] ? netlink_unicast+0x800/0x800<br /> [ 1010.716269] ? __import_iovec+0x292/0x510<br /> [ 1010.716276] ? netlink_unicast+0x800/0x800<br /> [ 1010.716284] __sock_sendmsg+0x159/0x190<br /> [ 1010.716290] ____sys_sendmsg+0x712/0x880<br /> [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0<br /> [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270<br /> [ 1010.716309] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716315] ? drain_array_locked+0x90/0x90<br /> [ 1010.716324] ___sys_sendmsg+0xf8/0x170<br /> [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170<br /> [ 1010.716337] ? lockdep_init_map<br /> ---truncated---