Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/gem: Fix error code msm_parse_deps()<br /> <br /> The SUBMIT_ERROR() macro turns the error code negative. This extra &amp;#39;-&amp;#39;<br /> operation turns it back to positive EINVAL again. The error code is<br /> passed to ERR_PTR() and since positive values are not an IS_ERR() it<br /> eventually will lead to an oops. Delete the &amp;#39;-&amp;#39;.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/637625/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()<br /> <br /> If track_pfn_copy() fails, we already added the dst VMA to the maple<br /> tree. As fork() fails, we&amp;#39;ll cleanup the maple tree, and stumble over<br /> the dst VMA for which we neither performed any reservation nor copied<br /> any page tables.<br /> <br /> Consequently untrack_pfn() will see VM_PAT and try obtaining the<br /> PAT information from the page table -- which fails because the page<br /> table was not copied.<br /> <br /> The easiest fix would be to simply clear the VM_PAT flag of the dst VMA<br /> if track_pfn_copy() fails. However, the whole thing is about "simply"<br /> clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()<br /> and performed a reservation, but copying the page tables fails, we&amp;#39;ll<br /> simply clear the VM_PAT flag, not properly undoing the reservation ...<br /> which is also wrong.<br /> <br /> So let&amp;#39;s fix it properly: set the VM_PAT flag only if the reservation<br /> succeeded (leaving it clear initially), and undo the reservation if<br /> anything goes wrong while copying the page tables: clearing the VM_PAT<br /> flag after undoing the reservation.<br /> <br /> Note that any copied page table entries will get zapped when the VMA will<br /> get removed later, after copy_page_range() succeeded; as VM_PAT is not set<br /> then, we won&amp;#39;t try cleaning VM_PAT up once more and untrack_pfn() will be<br /> happy. Note that leaving these page tables in place without a reservation<br /> is not a problem, as we are aborting fork(); this process will never run.<br /> <br /> A reproducer can trigger this usually at the first try:<br /> <br /> https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c<br /> <br /> WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110<br /> Modules linked in: ...<br /> CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:get_pat_info+0xf6/0x110<br /> ...<br /> Call Trace:<br /> <br /> ...<br /> untrack_pfn+0x52/0x110<br /> unmap_single_vma+0xa6/0xe0<br /> unmap_vmas+0x105/0x1f0<br /> exit_mmap+0xf6/0x460<br /> __mmput+0x4b/0x120<br /> copy_process+0x1bf6/0x2aa0<br /> kernel_clone+0xab/0x440<br /> __do_sys_clone+0x66/0x90<br /> do_syscall_64+0x95/0x180<br /> <br /> Likely this case was missed in:<br /> <br /> d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")<br /> <br /> ... and instead of undoing the reservation we simply cleared the VM_PAT flag.<br /> <br /> Keep the documentation of these functions in include/linux/pgtable.h,<br /> one place is more than sufficient -- we should clean that up for the other<br /> functions like track_pfn_remap/untrack_pfn separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/erdma: Prevent use-after-free in erdma_accept_newconn()<br /> <br /> After the erdma_cep_put(new_cep) being called, new_cep will be freed,<br /> and the following dereference will cause a UAF problem. Fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Don&amp;#39;t expose hw_counters outside of init net namespace<br /> <br /> Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs<br /> attributes") accidentally almost exposed hw counters to non-init net<br /> namespaces. It didn&amp;#39;t expose them fully, as an attempt to read any of<br /> those counters leads to a crash like this one:<br /> <br /> [42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> [42021.814463] #PF: supervisor read access in kernel mode<br /> [42021.819549] #PF: error_code(0x0000) - not-present page<br /> [42021.824636] PGD 0 P4D 0<br /> [42021.827145] Oops: 0000 [#1] SMP PTI<br /> [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX<br /> [42021.841697] Hardware name: XXX<br /> [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]<br /> [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48<br /> [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287<br /> [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000<br /> [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0<br /> [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000<br /> [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530<br /> [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000<br /> [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000<br /> [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0<br /> [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [42021.949324] Call Trace:<br /> [42021.951756] <br /> [42021.953842] [] ? show_regs+0x64/0x70<br /> [42021.959030] [] ? __die+0x78/0xc0<br /> [42021.963874] [] ? page_fault_oops+0x2b5/0x3b0<br /> [42021.969749] [] ? exc_page_fault+0x1a2/0x3c0<br /> [42021.975549] [] ? asm_exc_page_fault+0x26/0x30<br /> [42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]<br /> [42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core]<br /> [42021.995438] [] dev_attr_show+0x1e/0x50<br /> [42022.000803] [] sysfs_kf_seq_show+0x81/0xe0<br /> [42022.006508] [] seq_read_iter+0xf4/0x410<br /> [42022.011954] [] vfs_read+0x16e/0x2f0<br /> [42022.017058] [] ksys_read+0x6e/0xe0<br /> [42022.022073] [] do_syscall_64+0x6a/0xa0<br /> [42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The problem can be reproduced using the following steps:<br /> ip netns add foo<br /> ip netns exec foo bash<br /> cat /sys/class/infiniband/mlx4_0/hw_counters/*<br /> <br /> The panic occurs because of casting the device pointer into an<br /> ib_device pointer using container_of() in hw_stat_device_show() is<br /> wrong and leads to a memory corruption.<br /> <br /> However the real problem is that hw counters should never been exposed<br /> outside of the non-init net namespace.<br /> <br /> Fix this by saving the index of the corresponding attribute group<br /> (it might be 1 or 2 depending on the presence of driver-specific<br /> attributes) and zeroing the pointer to hw_counters group for compat<br /> devices during the initialization.<br /> <br /> With this fix applied hw_counters are not available in a non-init<br /> net namespace:<br /> find /sys/class/infiniband/mlx4_0/ -name hw_counters<br /> /sys/class/infiniband/mlx4_0/ports/1/hw_counters<br /> /sys/class/infiniband/mlx4_0/ports/2/hw_counters<br /> /sys/class/infiniband/mlx4_0/hw_counters<br /> <br /> ip netns add foo<br /> ip netns exec foo bash<br /> find /sys/class/infiniband/mlx4_0/ -name hw_counters

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: avoid NPD when ASIC does not support DMUB<br /> <br /> ctx-&gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is<br /> tested in dm_dmub_sw_init.<br /> <br /> However, it will be dereferenced in dmub_hw_lock_mgr_cmd if<br /> should_use_dmub_lock returns true.<br /> <br /> This has been the case since dmub support has been added for PSR1.<br /> <br /> Fix this by checking for dmub_srv in should_use_dmub_lock.<br /> <br /> [ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> [ 37.447808] #PF: supervisor read access in kernel mode<br /> [ 37.452959] #PF: error_code(0x0000) - not-present page<br /> [ 37.458112] PGD 0 P4D 0<br /> [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88<br /> [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023<br /> [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0<br /> [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5<br /> [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202<br /> [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358<br /> [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000<br /> [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5<br /> [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000<br /> [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000<br /> [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000<br /> [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0<br /> [ 37.572697] Call Trace:<br /> [ 37.575152] <br /> [ 37.577258] ? __die_body+0x66/0xb0<br /> [ 37.580756] ? page_fault_oops+0x3e7/0x4a0<br /> [ 37.584861] ? exc_page_fault+0x3e/0xe0<br /> [ 37.588706] ? exc_page_fault+0x5c/0xe0<br /> [ 37.592550] ? asm_exc_page_fault+0x22/0x30<br /> [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0<br /> [ 37.601107] dcn10_cursor_lock+0x1e1/0x240<br /> [ 37.605211] program_cursor_attributes+0x81/0x190<br /> [ 37.609923] commit_planes_for_stream+0x998/0x1ef0<br /> [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0<br /> [ 37.619703] dc_update_planes_and_stream+0x78/0x140<br /> [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0<br /> [ 37.629832] ? srso_return_thunk+0x5/0x5f<br /> [ 37.633847] ? mark_held_locks+0x6d/0xd0<br /> [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50<br /> [ 37.642135] ? srso_return_thunk+0x5/0x5f<br /> [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150<br /> [ 37.650510] ? srso_return_thunk+0x5/0x5f<br /> [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50<br /> [ 37.658883] ? srso_return_thunk+0x5/0x5f<br /> [ 37.662897] ? wait_for_common+0x186/0x1c0<br /> [ 37.666998] ? srso_return_thunk+0x5/0x5f<br /> [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170<br /> [ 37.675983] commit_tail+0xf5/0x1c0<br /> [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0<br /> [ 37.684186] drm_atomic_commit+0xd6/0x100<br /> [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10<br /> [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130<br /> [ 37.698054] drm_mode_cursor_common+0x501/0x670<br /> [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10<br /> [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70<br /> [ 37.711851] drm_ioctl_kernel+0xf2/0x150<br /> [ 37.715781] drm_ioctl+0x363/0x590<br /> [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10<br /> [ 37.724165] amdgpu_drm_ioctl+0x41/0x80<br /> [ 37.728013] __se_sys_ioctl+0x7f/0xd0<br /> [ 37.731685] do_syscall_64+0x87/0x100<br /> [ 37.735355] ? vma_end_read+0x12/0xe0<br /> [ 37.739024] ? srso_return_thunk+0x5/0x5f<br /> [ 37.743041] ? find_held_lock+0x47/0xf0<br /> [ 37.746884] ? vma_end_read+0x12/0xe0<br /> [ 37.750552] ? srso_return_thunk+0x5/0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: brcmstb: Fix error path after a call to regulator_bulk_get()<br /> <br /> If the regulator_bulk_get() returns an error and no regulators<br /> are created, we need to set their number to zero.<br /> <br /> If we don&amp;#39;t do this and the PCIe link up fails, a call to the<br /> regulator_bulk_free() will result in a kernel panic.<br /> <br /> While at it, print the error value, as we cannot return an error<br /> upwards as the kernel will WARN() on an error from add_bus().<br /> <br /> [kwilczynski: commit log, use comma in the message to match style with<br /> other similar messages]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vchiq_arm: Fix possible NPR of keep-alive thread<br /> <br /> In case vchiq_platform_conn_state_changed() is never called or fails before<br /> driver removal, ka_thread won&amp;#39;t be a valid pointer to a task_struct. So<br /> do the necessary checks before calling kthread_stop to avoid a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix array bounds error with may_goto<br /> <br /> may_goto uses an additional 8 bytes on the stack, which causes the<br /> interpreters[] array to go out of bounds when calculating index by<br /> stack_size.<br /> <br /> 1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT<br /> cases, reject loading directly.<br /> <br /> 2. For non-JIT cases, calculating interpreters[idx] may still cause<br /> out-of-bounds array access, and just warn about it.<br /> <br /> 3. For jit_requested cases, the execution of bpf_func also needs to be<br /> warned. So move the definition of function __bpf_prog_ret0_warn out of<br /> the macro definition CONFIG_BPF_JIT_ALWAYS_ON.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> w1: fix NULL pointer dereference in probe<br /> <br /> The w1_uart_probe() function calls w1_uart_serdev_open() (which includes<br /> devm_serdev_device_open()) before setting the client ops via<br /> serdev_device_set_client_ops(). This ordering can trigger a NULL pointer<br /> dereference in the serdev controller&amp;#39;s receive_buf handler, as it assumes<br /> serdev-&gt;ops is valid when SERPORT_ACTIVE is set.<br /> <br /> This is similar to the issue fixed in commit 5e700b384ec1<br /> ("platform/chrome: cros_ec_uart: properly fix race condition") where<br /> devm_serdev_device_open() was called before fully initializing the<br /> device.<br /> <br /> Fix the race by ensuring client ops are set before enabling the port via<br /> w1_uart_serdev_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: backend: make sure to NULL terminate stack buffer<br /> <br /> Make sure to NULL terminate the buffer in<br /> iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a<br /> stack variable so we should not assume it will 0 initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Prevent integer overflow in hdr_first_de()<br /> <br /> The "de_off" and "used" variables come from the disk so they both need to<br /> check. The problem is that on 32bit systems if they&amp;#39;re both greater than<br /> UINT_MAX - 16 then the check does work as intended because of an integer<br /> overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix use-after-free when rename device name<br /> <br /> Syzbot reported a slab-use-after-free with the following call trace:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099<br /> Read of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025<br /> <br /> CPU: 0 UID: 0 PID: 10025 Comm: syz.0.988<br /> Not tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0<br /> Hardware name: Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0x16e/0x5b0 mm/kasan/report.c:521<br /> kasan_report+0x143/0x180 mm/kasan/report.c:634<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105<br /> nla_put+0xd3/0x150 lib/nlattr.c:1099<br /> nla_put_string include/net/netlink.h:1621 [inline]<br /> fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265<br /> rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857<br /> ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344<br /> ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460<br /> rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540<br /> rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550<br /> rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212<br /> nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795<br /> rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]<br /> rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:709 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:724<br /> ____sys_sendmsg+0x53a/0x860 net/socket.c:2564<br /> ___sys_sendmsg net/socket.c:2618 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2650<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f42d1b8d169<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ...<br /> RSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169<br /> RDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c<br /> RBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8<br /> <br /> <br /> Allocated by task 10025:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4294 [inline]<br /> __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313<br /> __kmemdup_nul mm/util.c:61 [inline]<br /> kstrdup+0x42/0x100 mm/util.c:81<br /> kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274<br /> dev_set_name+0xd5/0x120 drivers/base/core.c:3468<br /> assign_name drivers/infiniband/core/device.c:1202 [inline]<br /> ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384<br /> rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540<br /> rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550<br /> rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212<br /> nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795<br /> rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]<br /> rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8de/0xcb0 net<br /> ---truncated---