xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23095: In the Linux kernel, the following vulnerability has been resolved:  gue: Fix skb memleak with inner IP protocol 0.  syzbot reported skb memleak below. [0]  The repro generated a GUE packet with its inner protocol 0.  gue_udp_recv() returns -guehdr->proto_ctype for "resubmit" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number.  Let's drop such packets.  Note that 0 is a valid number (IPv6 Hop-by-Hop Option).  I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:    * no error   * resubmit HOPOPT  [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240):   comm "syz.0.17", pid 6088, jiffies 4294943096   hex dump (first 32 bytes):     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................     00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............   backtrace (crc a84b336f):     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]     slab_post_alloc_hook mm/slub.c:4958 [inline]     slab_alloc_node mm/slub.c:5263 [inline]     kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270     __build_skb+0x23/0x60 net/core/skbuff.c:474     build_skb+0x20/0x190 net/core/skbuff.c:490     __tun_build_skb drivers/net/tun.c:1541 [inline]     tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636     tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770     tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999     new_sync_write fs/read_write.c:593 [inline]     vfs_write+0x45d/0x710 fs/read_write.c:686     ksys_write+0xa7/0x170 fs/read_write.c:738     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]     do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94     entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2026-23097: In the Linux kernel, the following vulnerability has been resolved:  migrate: correct lock ordering for hugetlb file folios  Syzbot has found a deadlock (analyzed by Lance Yang):  1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock.  migrate_pages()   -> migrate_hugetlbs()     -> unmap_and_move_huge_page()     <- Takes folio_lock!       -> remove_migration_ptes()         -> __rmap_walk_file()           -> i_mmap_lock_read()       <- Waits for i_mmap_rwsem(read lock)!  hugetlbfs_fallocate()   -> hugetlbfs_punch_hole()           <- Takes i_mmap_rwsem(write lock)!     -> hugetlbfs_zero_partial_page()      -> filemap_lock_hugetlb_folio()       -> filemap_lock_folio()         -> __filemap_get_folio        <- Waits for folio_lock!  The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c.  So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too.  This is (mostly) how it used to be after commit c0d0381ade79.  That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.
CVE-2026-23098: In the Linux kernel, the following vulnerability has been resolved:  netrom: fix double-free in nr_route_frame()  In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug.  Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.
CVE-2026-23099: In the Linux kernel, the following vulnerability has been resolved:  bonding: limit BOND_MODE_8023AD to Ethernet devices  BOND_MODE_8023AD makes sense for ARPHRD_ETHER only.  syzbot reported:   BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]  BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497  CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G             L      syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace:  <TASK>   dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120   print_address_description mm/kasan/report.c:378 [inline]   print_report+0xca/0x240 mm/kasan/report.c:482   kasan_report+0x118/0x150 mm/kasan/report.c:595  check_region_inline mm/kasan/generic.c:-1 [inline]   kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200   __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105   __hw_addr_create net/core/dev_addr_lists.c:63 [inline]   __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118   __dev_mc_add net/core/dev_addr_lists.c:868 [inline]   dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886   bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180   do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963   do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165   rtnl_changelink net/core/rtnetlink.c:3776 [inline]   __rtnl_newlink net/core/rtnetlink.c:3935 [inline]   rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072   rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958   netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550   netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]   netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344   netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894   sock_sendmsg_nosec net/socket.c:727 [inline]   __sock_sendmsg+0x21c/0x270 net/socket.c:742   ____sys_sendmsg+0x505/0x820 net/socket.c:2592   ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646   __sys_sendmsg+0x164/0x220 net/socket.c:2678   do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]   __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307   do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332  entry_SYSENTER_compat_after_hwframe+0x84/0x8e  </TASK>  The buggy address belongs to the variable:  lacpdu_mcast_addr+0x0/0x40
CVE-2026-23101: In the Linux kernel, the following vulnerability has been resolved:  leds: led-class: Only Add LED to leds_list when it is fully ready  Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized.  This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work.  This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in:   ------------[ cut here ]------------  WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390  Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025  ...  Call trace:   __flush_work+0x344/0x390 (P)   flush_work+0x2c/0x50   led_trigger_set+0x1c8/0x340   led_trigger_register+0x17c/0x1c0   led_trigger_register_simple+0x84/0xe8   snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]   do_one_initcall+0x5c/0x318   do_init_module+0x9c/0x2b8   load_module+0x7e0/0x998  Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.
CVE-2026-23103: In the Linux kernel, the following vulnerability has been resolved:  ipvlan: Make the addrs_lock be per port  Make the addrs_lock be per port, not per ipvlan dev.  Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So  1) Introduce per-port addrs_lock.  2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close)  This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:  1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock.  2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks  This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.
CVE-2026-23104: In the Linux kernel, the following vulnerability has been resolved:  ice: fix devlink reload call trace  Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. ice_hwmon_init() was added to ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur.  BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace:  string+0x48/0xe0  vsnprintf+0x1f9/0x650  sprintf+0x62/0x80  name_show+0x1f/0x30  dev_attr_show+0x19/0x60  The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory.  The sequence is: 1. Driver load, ice_hwmon_init() gets called from ice_init_feature() 2. Devlink reload down, flow does not call ice_remove() 3. Devlink reload up, ice_hwmon_init() gets called from    ice_init_feature() resulting in a second instance 4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the    first hwmon instance orphaned with dangling pointer  Fix this by moving ice_hwmon_exit() from ice_remove() to ice_deinit_features() to ensure proper cleanup symmetry with ice_hwmon_init().
CVE-2026-23108: In the Linux kernel, the following vulnerability has been resolved:  can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak  Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").  In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs().  Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.
CVE-2026-23110: In the Linux kernel, the following vulnerability has been resolved:  scsi: core: Wake up the error handler when final completions race against each other  The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.  First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count.  This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.  Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task.  This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.
CVE-2025-47911: The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.
CVE-2026-1774: CASL Ability, versions 2.4.0 through 6.7.4, contains a prototype pollution vulnerability.
CVE-2019-25314: Yoast Duplicate-Post WordPress Plugin 3.2.3 contains a persistent cross-site scripting vulnerability in plugin settings parameters. Attackers can inject malicious scripts into title prefix, suffix, menu order, and blacklist fields to execute arbitrary JavaScript in admin interfaces.
CVE-2026-20634: The issue was addressed with improved memory handling. This issue is fixed in watchOS 26.3, tvOS 26.3, macOS Tahoe 26.3, macOS Sonoma 14.8.4, macOS Sequoia 15.7.4, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3. Processing a maliciously crafted image may result in disclosure of process memory.
CVE-2025-14892: The Prime Listing Manager WordPress plugin through 1.1 allows an attacker to gain administrative access without having any kind of account on the targeted site and perform unauthorized actions due to a hardcoded secret.
CVE-2025-15520: The RegistrationMagic  WordPress plugin before 6.0.7.2 checks nonces but not capabilities, allowing for the disclosure of some sensitive data to subscribers and above.
CVE-2026-23111: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()  nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required.  nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.  Compare the non-catchall activate callback, which is correct:    nft_mapelem_activate():     if (nft_set_elem_active(ext, iter->genmask))         return 0;   /* skip active, process inactive */  With the buggy catchall version:    nft_map_catchall_activate():     if (!nft_set_elem_active(ext, genmask))         continue;   /* skip inactive, process active */  The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.  This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES.  Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.
CVE-2026-23112: In the Linux kernel, the following vulnerability has been resolved:  nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec  nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.
CVE-2025-71200: In the Linux kernel, the following vulnerability has been resolved:  mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode  When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz will lead to link broken as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these modes.  Add a check to prevent illegal clock reduction through debugfs:  root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [   30.090146] mmc0: running CQE recovery mmc0: cqhci: Failed to halt mmc0: cqhci: spurious TCN for tag 0 WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24 Modules linked in: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blk_mq_run_work_fn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhci_irq+0x254/0x818 lr : cqhci_irq+0x254/0x818 ...
CVE-2026-23115: In the Linux kernel, the following vulnerability has been resolved:  serial: Fix not set tty->port race condition  Revert commit bfc467db60b7 ("serial: remove redundant tty_port_link_device()") because the tty_port_link_device() is not redundant: the tty->port has to be confured before we call uart_configure_port(), otherwise user-space can open console without TTY linked to the driver.  This tty_port_link_device() was added explicitly to avoid this exact issue in commit fb2b90014d78 ("tty: link tty and port before configuring it as console"), so offending commit basically reverted the fix saying it is redundant without addressing the actual race condition presented there.  Reproducible always as tty->port warning on Qualcomm SoC with most of devices disabled, so with very fast boot, and one serial device being the console:    printk: legacy console [ttyMSM0] enabled   printk: legacy console [ttyMSM0] enabled   printk: legacy bootconsole [qcom_geni0] disabled   printk: legacy bootconsole [qcom_geni0] disabled   ------------[ cut here ]------------   tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!   WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1   Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6   CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S                  6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT   Tainted: [S]=CPU_OUT_OF_SPEC   Hardware name: Qualcomm Technologies, Inc. Eliza (DT)   ...   tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)   tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))   chrdev_open (fs/char_dev.c:411)   do_dentry_open (fs/open.c:962)   vfs_open (fs/open.c:1094)   do_open (fs/namei.c:4634)   path_openat (fs/namei.c:4793)   do_filp_open (fs/namei.c:4820)   do_sys_openat2 (fs/open.c:1391 (discriminator 3))   ...   Starting Network Name Resolution...  Apparently the flow with this small Yocto-based ramdisk user-space is:  driver (qcom_geni_serial.c):                  user-space: ============================                  =========== qcom_geni_serial_probe()  uart_add_one_port()   serial_core_register_port()    serial_core_add_one_port()     uart_configure_port()      register_console()     |     |                                         open console     |                                          ...     |                                          tty_init_dev()     |                                           driver->ports[idx] is NULL     |     tty_port_register_device_attr_serdev()      tty_port_link_device() <- set driver->ports[idx]
CVE-2026-23119: In the Linux kernel, the following vulnerability has been resolved:  bonding: provide a net pointer to __skb_flow_dissect()  After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer.  In the following case, syzbot was able to cook a bare skb.  WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace:  <TASK>   bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]   __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157   bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]   bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]   bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515   xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388   bpf_prog_run_xdp include/net/xdp.h:700 [inline]   bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421   bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390   bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703   __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182   __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]   __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]   __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]   do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
CVE-2026-23120: In the Linux kernel, the following vulnerability has been resolved:  l2tp: avoid one data-race in l2tp_tunnel_del_work()  We should read sk->sk_socket only when dealing with kernel sockets.  syzbot reported the following data-race:  BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release  write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:   sk_set_socket include/net/sock.h:2092 [inline]   sock_orphan include/net/sock.h:2118 [inline]   sk_common_release+0xae/0x230 net/core/sock.c:4003   udp_lib_close+0x15/0x20 include/net/udp.h:325   inet_release+0xce/0xf0 net/ipv4/af_inet.c:437   __sock_release net/socket.c:662 [inline]   sock_close+0x6b/0x150 net/socket.c:1455   __fput+0x29b/0x650 fs/file_table.c:468   ____fput+0x1c/0x30 fs/file_table.c:496   task_work_run+0x131/0x1a0 kernel/task_work.c:233   resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]   __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]   exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75   __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]   syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]   syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]   syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]   do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100  entry_SYSCALL_64_after_hwframe+0x77/0x7f  read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:   l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418   process_one_work kernel/workqueue.c:3257 [inline]   process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340   worker_thread+0x582/0x770 kernel/workqueue.c:3421   kthread+0x489/0x510 kernel/kthread.c:463   ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246  value changed: 0xffff88811b818000 -> 0x0000000000000000