Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/shmem-helper: Remove errant put in error path<br /> <br /> drm_gem_shmem_mmap() doesn&amp;#39;t own this reference, resulting in the GEM<br /> object getting prematurely freed leading to a later use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix crash when replugging CSR fake controllers<br /> <br /> It seems fake CSR 5.0 clones can cause the suspend notifier to be<br /> registered twice causing the following kernel panic:<br /> <br /> [ 71.986122] Call Trace:<br /> [ 71.986124] <br /> [ 71.986125] blocking_notifier_chain_register+0x33/0x60<br /> [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]<br /> [ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]<br /> [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300<br /> [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90<br /> [ 71.986167] usb_probe_interface+0xe3/0x2b0<br /> [ 71.986171] really_probe+0xdb/0x380<br /> [ 71.986174] ? pm_runtime_barrier+0x54/0x90<br /> [ 71.986177] __driver_probe_device+0x78/0x170<br /> [ 71.986180] driver_probe_device+0x1f/0x90<br /> [ 71.986183] __device_attach_driver+0x89/0x110<br /> [ 71.986186] ? driver_allows_async_probing+0x70/0x70<br /> [ 71.986189] bus_for_each_drv+0x8c/0xe0<br /> [ 71.986192] __device_attach+0xb2/0x1e0<br /> [ 71.986195] bus_probe_device+0x92/0xb0<br /> [ 71.986198] device_add+0x422/0x9a0<br /> [ 71.986201] ? sysfs_merge_group+0xd4/0x110<br /> [ 71.986205] usb_set_configuration+0x57a/0x820<br /> [ 71.986208] usb_generic_driver_probe+0x4f/0x70<br /> [ 71.986211] usb_probe_device+0x3a/0x110<br /> [ 71.986213] really_probe+0xdb/0x380<br /> [ 71.986216] ? pm_runtime_barrier+0x54/0x90<br /> [ 71.986219] __driver_probe_device+0x78/0x170<br /> [ 71.986221] driver_probe_device+0x1f/0x90<br /> [ 71.986224] __device_attach_driver+0x89/0x110<br /> [ 71.986227] ? driver_allows_async_probing+0x70/0x70<br /> [ 71.986230] bus_for_each_drv+0x8c/0xe0<br /> [ 71.986232] __device_attach+0xb2/0x1e0<br /> [ 71.986235] bus_probe_device+0x92/0xb0<br /> [ 71.986237] device_add+0x422/0x9a0<br /> [ 71.986239] ? _dev_info+0x7d/0x98<br /> [ 71.986242] ? blake2s_update+0x4c/0xc0<br /> [ 71.986246] usb_new_device.cold+0x148/0x36d<br /> [ 71.986250] hub_event+0xa8a/0x1910<br /> [ 71.986255] process_one_work+0x1c4/0x380<br /> [ 71.986259] worker_thread+0x51/0x390<br /> [ 71.986262] ? rescuer_thread+0x3b0/0x3b0<br /> [ 71.986264] kthread+0xdb/0x110<br /> [ 71.986266] ? kthread_complete_and_exit+0x20/0x20<br /> [ 71.986268] ret_from_fork+0x1f/0x30<br /> [ 71.986273] <br /> [ 71.986274] ---[ end trace 0000000000000000 ]---<br /> [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()<br /> <br /> Syzkaller reports a NULL deref bug as follows:<br /> <br /> BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3<br /> Read of size 4 at addr 0000000000000138 by task file1/1955<br /> <br /> CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> ? io_tctx_exit_cb+0x53/0xd3<br /> kasan_report+0xbb/0x1f0<br /> ? io_tctx_exit_cb+0x53/0xd3<br /> kasan_check_range+0x140/0x190<br /> io_tctx_exit_cb+0x53/0xd3<br /> task_work_run+0x164/0x250<br /> ? task_work_cancel+0x30/0x30<br /> get_signal+0x1c3/0x2440<br /> ? lock_downgrade+0x6e0/0x6e0<br /> ? lock_downgrade+0x6e0/0x6e0<br /> ? exit_signals+0x8b0/0x8b0<br /> ? do_raw_read_unlock+0x3b/0x70<br /> ? do_raw_spin_unlock+0x50/0x230<br /> arch_do_signal_or_restart+0x82/0x2470<br /> ? kmem_cache_free+0x260/0x4b0<br /> ? putname+0xfe/0x140<br /> ? get_sigframe_size+0x10/0x10<br /> ? do_execveat_common.isra.0+0x226/0x710<br /> ? lockdep_hardirqs_on+0x79/0x100<br /> ? putname+0xfe/0x140<br /> ? do_execveat_common.isra.0+0x238/0x710<br /> exit_to_user_mode_prepare+0x15f/0x250<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x42/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0023:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Kernel panic - not syncing: panic_on_warn set ...<br /> <br /> This happens because the adding of task_work from io_ring_exit_work()<br /> isn&amp;#39;t synchronized with canceling all work items from eg exec. The<br /> execution of the two are ordered in that they are both run by the task<br /> itself, but if io_tctx_exit_cb() is queued while we&amp;#39;re canceling all<br /> work items off exec AND gets executed when the task exits to userspace<br /> rather than in the main loop in io_uring_cancel_generic(), then we can<br /> find current-&gt;io_uring == NULL and hit the above crash.<br /> <br /> It&amp;#39;s safe to add this NULL check here, because the execution of the two<br /> paths are done by the task itself.<br /> <br /> [axboe: add code comment and also put an explanation in the commit msg]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: slcan: fix freed work crash<br /> <br /> The LTP test pty03 is causing a crash in slcan:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014<br /> Workqueue: 0x0 (events)<br /> RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)<br /> Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e<br /> RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968<br /> RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0<br /> RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734<br /> R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000<br /> R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0<br /> FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436)<br /> kthread (/home/rich/kernel/linux/kernel/kthread.c:376)<br /> ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)<br /> <br /> Apparently, the slcan&amp;#39;s tx_work is freed while being scheduled. While<br /> slcan_netdev_close() (netdev side) calls flush_work(&amp;sl-&gt;tx_work),<br /> slcan_close() (tty side) does not. So when the netdev is never set UP,<br /> but the tty is stuffed with bytes and forced to wakeup write, the work<br /> is scheduled, but never flushed.<br /> <br /> So add an additional flush_work() to slcan_close() to be sure the work<br /> is flushed under all circumstances.<br /> <br /> The Fixes commit below moved flush_work() from slcan_close() to<br /> slcan_netdev_close(). What was the rationale behind it? Maybe we can<br /> drop the one in slcan_netdev_close()?<br /> <br /> I see the same pattern in can327. So it perhaps needs the very same fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix race on per-CQ variable napi work_done<br /> <br /> After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be<br /> cleared, and another CPU can start napi thread and access per-CQ variable,<br /> cq-&gt;work_done. If the other thread (for example, from busy_poll) sets<br /> it to a value &gt;= budget, this thread will continue to run when it should<br /> stop, and cause memory corruption and panic.<br /> <br /> To fix this issue, save the per-CQ work_done variable in a local variable<br /> before napi_complete_done(), so it won&amp;#39;t be corrupted by a possible<br /> concurrent thread after napi_complete_done().<br /> <br /> Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done<br /> variable race is fixed, so the driver is able to reliably support features<br /> like busy_poll.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/gup: fix gup_pud_range() for dax<br /> <br /> For dax pud, pud_huge() returns true on x86. So the function works as long<br /> as hugetlb is configured. However, dax doesn&amp;#39;t depend on hugetlb.<br /> Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed<br /> devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as<br /> well.<br /> <br /> This fixes the below kernel panic:<br /> <br /> general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP<br /> <br /> Call Trace:<br /> <br /> get_user_pages_fast+0x1f/0x40<br /> iov_iter_get_pages+0xc6/0x3b0<br /> ? mempool_alloc+0x5d/0x170<br /> bio_iov_iter_get_pages+0x82/0x4e0<br /> ? bvec_alloc+0x91/0xc0<br /> ? bio_alloc_bioset+0x19a/0x2a0<br /> blkdev_direct_IO+0x282/0x480<br /> ? __io_complete_rw_common+0xc0/0xc0<br /> ? filemap_range_has_page+0x82/0xc0<br /> generic_file_direct_write+0x9d/0x1a0<br /> ? inode_update_time+0x24/0x30<br /> __generic_file_write_iter+0xbd/0x1e0<br /> blkdev_write_iter+0xb4/0x150<br /> ? io_import_iovec+0x8d/0x340<br /> io_write+0xf9/0x300<br /> io_issue_sqe+0x3c3/0x1d30<br /> ? sysvec_reschedule_ipi+0x6c/0x80<br /> __io_queue_sqe+0x33/0x240<br /> ? fget+0x76/0xa0<br /> io_submit_sqes+0xe6a/0x18d0<br /> ? __fget_light+0xd1/0x100<br /> __x64_sys_io_uring_enter+0x199/0x880<br /> ? __context_tracking_enter+0x1f/0x70<br /> ? irqentry_exit_to_user_mode+0x24/0x30<br /> ? irqentry_exit+0x1d/0x30<br /> ? __context_tracking_exit+0xe/0x70<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x61/0xcb<br /> RIP: 0033:0x7fc97c11a7be<br /> <br /> <br /> ---[ end trace 48b2e0e67debcaeb ]---<br /> RIP: 0010:internal_get_user_pages_fast+0x340/0x990<br /> <br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: disabled

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-dv-timings.c: fix too strict blanking sanity checks<br /> <br /> Sanity checks were added to verify the v4l2_bt_timings blanking fields<br /> in order to avoid integer overflows when userspace passes weird values.<br /> <br /> But that assumed that userspace would correctly fill in the front porch,<br /> backporch and sync values, but sometimes all you know is the total<br /> blanking, which is then assigned to just one of these fields.<br /> <br /> And that can fail with these checks.<br /> <br /> So instead set a maximum for the total horizontal and vertical<br /> blanking and check that each field remains below that.<br /> <br /> That is still sufficient to avoid integer overflows, but it also<br /> allows for more flexibility in how userspace fills in these fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memcg: fix possible use-after-free in memcg_write_event_control()<br /> <br /> memcg_write_event_control() accesses the dentry-&gt;d_name of the specified<br /> control fd to route the write call. As a cgroup interface file can&amp;#39;t be<br /> renamed, it&amp;#39;s safe to access d_name as long as the specified file is a<br /> regular cgroup file. Also, as these cgroup interface files can&amp;#39;t be<br /> removed before the directory, it&amp;#39;s safe to access the parent too.<br /> <br /> Prior to 347c4a874710 ("memcg: remove cgroup_event-&gt;cft"), there was a<br /> call to __file_cft() which verified that the specified file is a regular<br /> cgroupfs file before further accesses. The cftype pointer returned from<br /> __file_cft() was no longer necessary and the commit inadvertently dropped<br /> the file type check with it allowing any file to slip through. With the<br /> invarients broken, the d_name and parent accesses can now race against<br /> renames and removals of arbitrary files and cause use-after-free&amp;#39;s.<br /> <br /> Fix the bug by resurrecting the file type check in __file_cft(). Now that<br /> cgroupfs is implemented through kernfs, checking the file operations needs<br /> to go through a layer of indirection. Instead, let&amp;#39;s check the superblock<br /> and dentry type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscache: Fix oops due to race with cookie_lru and use_cookie<br /> <br /> If a cookie expires from the LRU and the LRU_DISCARD flag is set, but<br /> the state machine has not run yet, it&amp;#39;s possible another thread can call<br /> fscache_use_cookie and begin to use it.<br /> <br /> When the cookie_worker finally runs, it will see the LRU_DISCARD flag<br /> set, transition the cookie-&gt;state to LRU_DISCARDING, which will then<br /> withdraw the cookie. Once the cookie is withdrawn the object is removed<br /> the below oops will occur because the object associated with the cookie<br /> is now NULL.<br /> <br /> Fix the oops by clearing the LRU_DISCARD bit if another thread uses the<br /> cookie before the cookie_worker runs.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> ...<br /> CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022<br /> Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs]<br /> RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles]<br /> ...<br /> Call Trace:<br /> netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs]<br /> process_one_work+0x217/0x3e0<br /> worker_thread+0x4a/0x3b0<br /> kthread+0xd6/0x100

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix use-after-free during gpu recovery<br /> <br /> [Why]<br /> [ 754.862560] refcount_t: underflow; use-after-free.<br /> [ 754.862898] Call Trace:<br /> [ 754.862903] <br /> [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]<br /> [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched]<br /> <br /> [How]<br /> The fw_fence may be not init, check whether dma_fence_init<br /> is performed before job free

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: Fix NULL sring after live migration<br /> <br /> A NAPI is setup for each network sring to poll data to kernel<br /> The sring with source host is destroyed before live migration and<br /> new sring with target host is setup after live migration.<br /> The NAPI for the old sring is not deleted until setup new sring<br /> with target host after migration. With busy_poll/busy_read enabled,<br /> the NAPI can be polled before got deleted when resume VM.<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at<br /> 0000000000000008<br /> IP: xennet_poll+0xae/0xd20<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> Call Trace:<br /> finish_task_switch+0x71/0x230<br /> timerqueue_del+0x1d/0x40<br /> hrtimer_try_to_cancel+0xb5/0x110<br /> xennet_alloc_rx_buffers+0x2a0/0x2a0<br /> napi_busy_loop+0xdb/0x270<br /> sock_poll+0x87/0x90<br /> do_sys_poll+0x26f/0x580<br /> tracing_map_insert+0x1d4/0x2f0<br /> event_hist_trigger+0x14a/0x260<br /> <br /> finish_task_switch+0x71/0x230<br /> __schedule+0x256/0x890<br /> recalc_sigpending+0x1b/0x50<br /> xen_sched_clock+0x15/0x20<br /> __rb_reserve_next+0x12d/0x140<br /> ring_buffer_lock_reserve+0x123/0x3d0<br /> event_triggers_call+0x87/0xb0<br /> trace_event_buffer_commit+0x1c4/0x210<br /> xen_clocksource_get_cycles+0x15/0x20<br /> ktime_get_ts64+0x51/0xf0<br /> SyS_ppoll+0x160/0x1a0<br /> SyS_ppoll+0x160/0x1a0<br /> do_syscall_64+0x73/0x130<br /> entry_SYSCALL_64_after_hwframe+0x41/0xa6<br /> ...<br /> RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900<br /> CR2: 0000000000000008<br /> ---[ end trace f8601785b354351c ]---<br /> <br /> xen frontend should remove the NAPIs for the old srings before live<br /> migration as the bond srings are destroyed<br /> <br /> There is a tiny window between the srings are set to NULL and<br /> the NAPIs are disabled, It is safe as the NAPI threads are still<br /> frozen at that time

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Get user_ns from in_skb in unix_diag_get_exact().<br /> <br /> Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed<br /> the root cause: in unix_diag_get_exact(), the newly allocated skb does not<br /> have sk. [2]<br /> <br /> We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to<br /> sk_diag_fill().<br /> <br /> [0]:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000270<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]<br /> RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]<br /> RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170<br /> Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8<br /> 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd 8b<br /> 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d<br /> RSP: 0018:ffffc90000d67968 EFLAGS: 00010246<br /> RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d<br /> RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270<br /> RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000<br /> R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800<br /> R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940<br /> FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> unix_diag_get_exact net/unix/diag.c:285 [inline]<br /> unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317<br /> __sock_diag_cmd net/core/sock_diag.c:235 [inline]<br /> sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266<br /> netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564<br /> sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]<br /> netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356<br /> netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0x38f/0x500 net/socket.c:2476<br /> ___sys_sendmsg net/socket.c:2530 [inline]<br /> __sys_sendmsg+0x197/0x230 net/socket.c:2559<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x4697f9<br /> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48<br /> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d<br /> 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9<br /> RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003<br /> RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80<br /> R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0<br /> <br /> Modules linked in:<br /> CR2: 0000000000000270<br /> <br /> [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/<br /> [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/