Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kasan: avoid sleepable page allocation from atomic context<br /> <br /> apply_to_pte_range() enters the lazy MMU mode and then invokes<br /> kasan_populate_vmalloc_pte() callback on each page table walk iteration. <br /> However, the callback can go into sleep when trying to allocate a single<br /> page, e.g. if an architecutre disables preemption on lazy MMU mode enter.<br /> <br /> On s390 if make arch_enter_lazy_mmu_mode() -&gt; preempt_enable() and<br /> arch_leave_lazy_mmu_mode() -&gt; preempt_disable(), such crash occurs:<br /> <br /> [ 0.663336] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321<br /> [ 0.663348] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd<br /> [ 0.663358] preempt_count: 1, expected: 0<br /> [ 0.663366] RCU nest depth: 0, expected: 0<br /> [ 0.663375] no locks held by kthreadd/2.<br /> [ 0.663383] Preemption disabled at:<br /> [ 0.663386] [] apply_to_pte_range+0xfa/0x4a0<br /> [ 0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT<br /> [ 0.663408] Hardware name: IBM 3931 A01 701 (KVM/Linux)<br /> [ 0.663409] Call Trace:<br /> [ 0.663410] [] dump_stack_lvl+0xe8/0x140<br /> [ 0.663413] [] __might_resched+0x66e/0x700<br /> [ 0.663415] [] __alloc_frozen_pages_noprof+0x370/0x4b0<br /> [ 0.663419] [] alloc_pages_mpol+0x1a0/0x4a0<br /> [ 0.663421] [] alloc_frozen_pages_noprof+0x88/0xc0<br /> [ 0.663424] [] alloc_pages_noprof+0x22/0x120<br /> [ 0.663427] [] get_free_pages_noprof+0x2c/0xc0<br /> [ 0.663429] [] kasan_populate_vmalloc_pte+0x50/0x120<br /> [ 0.663433] [] apply_to_pte_range+0x118/0x4a0<br /> [ 0.663435] [] apply_to_pmd_range+0x194/0x3e0<br /> [ 0.663437] [] __apply_to_page_range+0x2fe/0x7a0<br /> [ 0.663440] [] apply_to_page_range+0x28/0x40<br /> [ 0.663442] [] kasan_populate_vmalloc+0x82/0xa0<br /> [ 0.663445] [] alloc_vmap_area+0x34c/0xc10<br /> [ 0.663448] [] __get_vm_area_node+0x186/0x2a0<br /> [ 0.663451] [] __vmalloc_node_range_noprof+0x116/0x310<br /> [ 0.663454] [] __vmalloc_node_noprof+0xd0/0x110<br /> [ 0.663457] [] alloc_thread_stack_node+0xf8/0x330<br /> [ 0.663460] [] dup_task_struct+0x66/0x4d0<br /> [ 0.663463] [] copy_process+0x280/0x4b90<br /> [ 0.663465] [] kernel_clone+0xd0/0x4b0<br /> [ 0.663467] [] kernel_thread+0xbe/0xe0<br /> [ 0.663469] [] kthreadd+0x50e/0x7f0<br /> [ 0.663472] [] __ret_from_fork+0x8a/0xf0<br /> [ 0.663475] [] ret_from_fork+0xa/0x38<br /> <br /> Instead of allocating single pages per-PTE, bulk-allocate the shadow<br /> memory prior to applying kasan_populate_vmalloc_pte() callback on a page<br /> range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS/localio: Fix a race in nfs_local_open_fh()<br /> <br /> Once the clp-&gt;cl_uuid.lock has been dropped, another CPU could come in<br /> and free the struct nfsd_file that was just added. To prevent that from<br /> happening, take the RCU read lock before dropping the spin lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7606: check for NULL before calling sw_mode_config()<br /> <br /> Check that the sw_mode_config function pointer is not NULL before<br /> calling it. Not all buses define this callback, which resulted in a NULL<br /> pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xcf/0x610 mm/kasan/report.c:489<br /> kasan_report+0xb5/0xe0 mm/kasan/report.c:602<br /> rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195<br /> rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132<br /> __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232<br /> rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109<br /> create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052<br /> ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095<br /> ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679<br /> vfs_write fs/read_write.c:677 [inline]<br /> vfs_write+0x26a/0xcc0 fs/read_write.c:659<br /> ksys_write+0x1b8/0x200 fs/read_write.c:731<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> In the function rxe_create_cq, when rxe_cq_from_init fails, the function<br /> rxe_cleanup will be called to handle the allocated resources. In fact,<br /> some memory resources have already been freed in the function<br /> rxe_cq_from_init. Thus, this problem will occur.<br /> <br /> The solution is to let rxe_cleanup do all the work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: handle failure of nfs_get_lock_context in unlock path<br /> <br /> When memory is insufficient, the allocation of nfs_lock_context in<br /> nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat<br /> an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)<br /> as valid and proceed to execute rpc_run_task(), this will trigger a NULL<br /> pointer dereference in nfs4_locku_prepare. For example:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000000c<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40<br /> Workqueue: rpciod rpc_async_schedule<br /> RIP: 0010:nfs4_locku_prepare+0x35/0xc2<br /> Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3<br /> RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246<br /> RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40<br /> RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38<br /> R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030<br /> R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30<br /> FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> __rpc_execute+0xbc/0x480<br /> rpc_async_schedule+0x2f/0x40<br /> process_one_work+0x232/0x5d0<br /> worker_thread+0x1da/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10d/0x240<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Modules linked in:<br /> CR2: 000000000000000c<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and<br /> return NULL to terminate subsequent rpc_run_task, preventing NULL pointer<br /> dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: max20086: fix invalid memory access<br /> <br /> max20086_parse_regulators_dt() calls of_regulator_match() using an<br /> array of struct of_regulator_match allocated on the stack for the<br /> matches argument.<br /> <br /> of_regulator_match() calls devm_of_regulator_put_matches(), which calls<br /> devres_alloc() to allocate a struct devm_of_regulator_matches which will<br /> be de-allocated using devm_of_regulator_put_matches().<br /> <br /> struct devm_of_regulator_matches is populated with the stack allocated<br /> matches array.<br /> <br /> If the device fails to probe, devm_of_regulator_put_matches() will be<br /> called and will try to call of_node_put() on that stack pointer,<br /> generating the following dmesg entries:<br /> <br /> max20086 6-0028: Failed to read DEVICE_ID reg: -121<br /> kobject: &amp;#39;\xc0$\xa5\x03&amp;#39; (000000002cebcb7a): is not initialized, yet<br /> kobject_put() is being called.<br /> <br /> Followed by a stack trace matching the call flow described above.<br /> <br /> Switch to allocating the matches array using devm_kcalloc() to<br /> avoid accessing the stack pointer long after it&amp;#39;s out of scope.<br /> <br /> This also has the advantage of allowing multiple max20086 to probe<br /> without overriding the data stored inside the global of_regulator_match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check of pipe_ctx-&gt;plane_state for update_dchubp_dpp<br /> <br /> Similar to commit 6a057072ddd1 ("drm/amd/display: Fix null check for<br /> pipe_ctx-&gt;plane_state in dcn20_program_pipe") that addresses a null<br /> pointer dereference on dcn20_update_dchubp_dpp. This is the same<br /> function hooked for update_dchubp_dpp in dcn401, with the same issue.<br /> Fix possible null pointer deference on dcn401_program_pipe too.<br /> <br /> (cherry picked from commit d8d47f739752227957d8efc0cb894761bfe1d879)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices<br /> <br /> The driver only offloads neighbors that are constructed on top of net<br /> devices registered by it or their uppers (which are all Ethernet). The<br /> device supports GRE encapsulation and decapsulation of forwarded<br /> traffic, but the driver will not offload dummy neighbors constructed on<br /> top of GRE net devices as they are not uppers of its net devices:<br /> <br /> # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1<br /> # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1<br /> $ ip neigh show dev gre1 nud noarp<br /> 0.0.0.0 lladdr 0.0.0.0 NOARP<br /> <br /> (Note that the neighbor is not marked with &amp;#39;offload&amp;#39;)<br /> <br /> When the driver is reloaded and the existing configuration is replayed,<br /> the driver does not perform the same check regarding existing neighbors<br /> and offloads the previously added one:<br /> <br /> # devlink dev reload pci/0000:01:00.0<br /> $ ip neigh show dev gre1 nud noarp<br /> 0.0.0.0 lladdr 0.0.0.0 offload NOARP<br /> <br /> If the neighbor is later deleted, the driver will ignore the<br /> notification (given the GRE net device is not its upper) and will<br /> therefore keep referencing freed memory, resulting in a use-after-free<br /> [1] when the net device is deleted:<br /> <br /> # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1<br /> # ip link del dev gre1<br /> <br /> Fix by skipping neighbor replay if the net device for which the replay<br /> is performed is not our upper.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200<br /> Read of size 8 at addr ffff888155b0e420 by task ip/2282<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6f/0x350<br /> print_report+0x108/0x205<br /> kasan_report+0xdf/0x110<br /> mlxsw_sp_neigh_entry_update+0x1ea/0x200<br /> mlxsw_sp_router_rif_gone_sync+0x2a8/0x440<br /> mlxsw_sp_rif_destroy+0x1e9/0x750<br /> mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0<br /> mlxsw_sp_router_netdevice_event+0x3ac/0x15e0<br /> notifier_call_chain+0xca/0x150<br /> call_netdevice_notifiers_info+0x7f/0x100<br /> unregister_netdevice_many_notify+0xc8c/0x1d90<br /> rtnl_dellink+0x34e/0xa50<br /> rtnetlink_rcv_msg+0x6fb/0xb70<br /> netlink_rcv_skb+0x131/0x360<br /> netlink_unicast+0x426/0x710<br /> netlink_sendmsg+0x75a/0xc20<br /> __sock_sendmsg+0xc1/0x150<br /> ____sys_sendmsg+0x5aa/0x7b0<br /> ___sys_sendmsg+0xfc/0x180<br /> __sys_sendmsg+0x121/0x1b0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/eventpoll: fix endless busy loop after timeout has expired<br /> <br /> After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it&amp;#39;s in<br /> the future"), the following program would immediately enter a busy<br /> loop in the kernel:<br /> <br /> ```<br /> int main() {<br /> int e = epoll_create1(0);<br /> struct epoll_event event = {.events = EPOLLIN};<br /> epoll_ctl(e, EPOLL_CTL_ADD, 0, &amp;event);<br /> const struct timespec timeout = {.tv_nsec = 1};<br /> epoll_pwait2(e, &amp;event, 1, &amp;timeout, 0);<br /> }<br /> ```<br /> <br /> This happens because the given (non-zero) timeout of 1 nanosecond<br /> usually expires before ep_poll() is entered and then<br /> ep_schedule_timeout() returns false, but `timed_out` is never set<br /> because the code line that sets it is skipped. This quickly turns<br /> into a soft lockup, RCU stalls and deadlocks, inflicting severe<br /> headaches to the whole system.<br /> <br /> When the timeout has expired, we don&amp;#39;t need to schedule a hrtimer, but<br /> we should set the `timed_out` variable. Therefore, I suggest moving<br /> the ep_schedule_timeout() check into the `timed_out` expression<br /> instead of skipping it.<br /> <br /> brauner: Note that there was an earlier fix by Joe Damato in response to<br /> my bug report in [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: bpf: abort dispatch if device destroyed<br /> <br /> The current HID bpf implementation assumes no output report/request will<br /> go through it after hid_bpf_destroy_device() has been called. This leads<br /> to a bug that unplugging certain types of HID devices causes a cleaned-<br /> up SRCU to be accessed. The bug was previously a hidden failure until a<br /> recent x86 percpu change [1] made it access not-present pages.<br /> <br /> The bug will be triggered if the conditions below are met:<br /> <br /> A) a device under the driver has some LEDs on<br /> B) hid_ll_driver-&gt;request() is uninplemented (e.g., logitech-djreceiver)<br /> <br /> If condition A is met, hidinput_led_worker() is always scheduled *after*<br /> hid_bpf_destroy_device().<br /> <br /> hid_destroy_device<br /> ` hid_bpf_destroy_device<br /> ` cleanup_srcu_struct(&amp;hdev-&gt;bpf.srcu)<br /> ` hid_remove_device<br /> ` ...<br /> ` led_classdev_unregister<br /> ` led_trigger_set(led_cdev, NULL)<br /> ` led_set_brightness(led_cdev, LED_OFF)<br /> ` ...<br /> ` input_inject_event<br /> ` input_event_dispose<br /> ` hidinput_input_event<br /> ` schedule_work(&amp;hid-&gt;led_work) [hidinput_led_worker]<br /> <br /> This is fine when condition B is not met, where hidinput_led_worker()<br /> calls hid_ll_driver-&gt;request(). This is the case for most HID drivers,<br /> which implement it or use the generic one from usbhid. The driver itself<br /> or an underlying driver will then abort processing the request.<br /> <br /> Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads<br /> to the bug.<br /> <br /> hidinput_led_worker<br /> ` hid_hw_output_report<br /> ` dispatch_hid_bpf_output_report<br /> ` srcu_read_lock(&amp;hdev-&gt;bpf.srcu)<br /> ` srcu_read_unlock(&amp;hdev-&gt;bpf.srcu, idx)<br /> <br /> The bug has existed since the introduction [2] of<br /> dispatch_hid_bpf_output_report(). However, the same bug also exists in<br /> dispatch_hid_bpf_raw_requests(), and I&amp;#39;ve reproduced (no visible effect<br /> because of the lack of [1], but confirmed bpf.destroyed == 1) the bug<br /> against the commit (i.e., the Fixes:) introducing the function. This is<br /> because hidinput_led_worker() falls back to hid_hw_raw_request() when<br /> hid_ll_driver-&gt;output_report() is uninplemented (e.g., logitech-<br /> djreceiver).<br /> <br /> hidinput_led_worker<br /> ` hid_hw_output_report: -ENOSYS<br /> ` hid_hw_raw_request<br /> ` dispatch_hid_bpf_raw_requests<br /> ` srcu_read_lock(&amp;hdev-&gt;bpf.srcu)<br /> ` srcu_read_unlock(&amp;hdev-&gt;bpf.srcu, idx)<br /> <br /> Fix the issue by returning early in the two mentioned functions if<br /> hid_bpf has been marked as destroyed. Though<br /> dispatch_hid_bpf_device_event() handles input events, and there is no<br /> evidence that it may be called after the destruction, the same check, as<br /> a safety net, is also added to it to maintain the consistency among all<br /> dispatch functions.<br /> <br /> The impact of the bug on other architectures is unclear. Even if it acts<br /> as a hidden failure, this is still dangerous because it corrupts<br /> whatever is on the address calculated by SRCU. Thus, CC&amp;#39;ing the stable<br /> list.<br /> <br /> [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets")<br /> [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for<br /> hid_hw_output_report")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Disable MACsec offload for uplink representor profile<br /> <br /> MACsec offload is not supported in switchdev mode for uplink<br /> representors. When switching to the uplink representor profile, the<br /> MACsec offload feature must be cleared from the netdevice&amp;#39;s features.<br /> <br /> If left enabled, attempts to add offloads result in a null pointer<br /> dereference, as the uplink representor does not support MACsec offload<br /> even though the feature bit remains set.<br /> <br /> Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().<br /> <br /> Kernel log:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__mutex_lock+0x128/0x1dd0<br /> Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff<br /> RSP: 0018:ffff888147a4f160 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078<br /> RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000<br /> FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x3d/0xa0<br /> ? exc_general_protection+0x144/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? __mutex_lock+0x128/0x1dd0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mutex_lock_io_nested+0x1ae0/0x1ae0<br /> ? lock_acquire+0x1c2/0x530<br /> ? macsec_upd_offload+0x145/0x380<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? kasan_save_stack+0x30/0x40<br /> ? kasan_save_stack+0x20/0x40<br /> ? kasan_save_track+0x10/0x30<br /> ? __kasan_kmalloc+0x77/0x90<br /> ? __kmalloc_noprof+0x249/0x6b0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]<br /> macsec_update_offload+0x26c/0x820<br /> ? macsec_set_mac_address+0x4b0/0x4b0<br /> ? lockdep_hardirqs_on_prepare+0x284/0x400<br /> ? _raw_spin_unlock_irqrestore+0x47/0x50<br /> macsec_upd_offload+0x2c8/0x380<br /> ? macsec_update_offload+0x820/0x820<br /> ? __nla_parse+0x22/0x30<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240<br /> genl_family_rcv_msg_doit+0x1cc/0x2a0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240<br /> ? cap_capable+0xd4/0x330<br /> genl_rcv_msg+0x3ea/0x670<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? macsec_update_offload+0x820/0x820<br /> netlink_rcv_skb+0x12b/0x390<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? netlink_ack+0xd80/0xd80<br /> ? rwsem_down_read_slowpath+0xf90/0xf90<br /> ? netlink_deliver_tap+0xcd/0xac0<br /> ? netlink_deliver_tap+0x155/0xac0<br /> ? _copy_from_iter+0x1bb/0x12c0<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x440/0x700<br /> ? netlink_attachskb+0x760/0x760<br /> ? lock_acquire+0x1c2/0x530<br /> ? __might_fault+0xbb/0x170<br /> netlink_sendmsg+0x749/0xc10<br /> ? netlink_unicast+0x700/0x700<br /> ? __might_fault+0xbb/0x170<br /> ? netlink_unicast+0x700/0x700<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x53f/0x760<br /> ? import_iovec+0x7/0x10<br /> ? kernel_sendmsg+0x30/0x30<br /> ? __copy_msghdr+0x3c0/0x3c0<br /> ? filter_irq_stacks+0x90/0x90<br /> ? stack_depot_save_flags+0x28/0xa30<br /> ___sys_sen<br /> ---truncated---