xamxte/cve-to-cwe huggingface dataset:
CVE-2024-42276: In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: add missing condition check for existence of mapped data  nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.
CVE-2024-42291: In the Linux kernel, the following vulnerability has been resolved:  ice: Add a per-VF limit on number of FDIR filters  While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs.  Add a similar limit in ice.
CVE-2024-42318: In the Linux kernel, the following vulnerability has been resolved:  landlock: Don't lose track of restrictions on cred_transfer  When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead.  Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost.  This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself.  Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.)
CVE-2024-43831: In the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Handle invalid decoder vsi  Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use.
CVE-2024-43832: In the Linux kernel, the following vulnerability has been resolved:  s390/uv: Don't call folio_wait_writeback() without a folio reference  folio_wait_writeback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference.
CVE-2024-43840: In the Linux kernel, the following vulnerability has been resolved:  bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG  When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them the struct bpf_tramp_image *im pointer as an argument in R0.  The trampoline generation code uses emit_addr_mov_i64() to emit instructions for moving the bpf_tramp_image address into R0, but emit_addr_mov_i64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpf_tramp_image is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to __bpf_tramp_enter/exit() causing a kernel crash.  Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64() as it can work with addresses that are greater than 48-bits.
CVE-2024-43841: In the Linux kernel, the following vulnerability has been resolved:  wifi: virt_wifi: avoid reporting connection success with wrong SSID  When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found).  The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning.  Fixed it by checking the SSID (from user space) in the connection code.
CVE-2024-43847: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: fix invalid memory access while processing fragmented packets  The monitor ring and the reo reinject ring share the same ring mask index. When the driver receives an interrupt for the reo reinject ring, the monitor ring is also processed, leading to invalid memory access. Since monitor support is not yet enabled in ath12k, the ring mask for the monitor ring should be removed.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
CVE-2024-43850: In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove  The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use.  Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]---
CVE-2024-44070: An issue was discovered in FRRouting (FRR) through 10.1. bgp_attr_encap in bgpd/bgp_attr.c does not check the actual remaining stream length before taking the TLV value.
CVE-2024-6330: The GEO my WP WordPress plugin before 4.5.0.2 does not prevent unauthenticated attackers from including arbitrary files in PHP's execution context, which leads to Remote Code Execution.
CVE-2022-48877: In the Linux kernel, the following vulnerability has been resolved:  f2fs: let's avoid panic if extent_tree is not created  This patch avoids the below panic.  pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace:  __lookup_extent_tree+0xd8/0x760  f2fs_do_write_data_page+0x104/0x87c  f2fs_write_single_data_page+0x420/0xb60  f2fs_write_cache_pages+0x418/0xb1c  __f2fs_write_data_pages+0x428/0x58c  f2fs_write_data_pages+0x30/0x40  do_writepages+0x88/0x190  __writeback_single_inode+0x48/0x448  writeback_sb_inodes+0x468/0x9e8  __writeback_inodes_wb+0xb8/0x2a4  wb_writeback+0x33c/0x740  wb_do_writeback+0x2b4/0x400  wb_workfn+0xe4/0x34c  process_one_work+0x24c/0x5bc  worker_thread+0x3e8/0xa50  kthread+0x150/0x1b4
CVE-2022-48880: In the Linux kernel, the following vulnerability has been resolved:  platform/surface: aggregator: Add missing call to ssam_request_sync_free()  Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this.
CVE-2022-48881: In the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd: Fix refcount leak in amd_pmc_probe  pci_get_domain_bus_and_slot() takes reference, the caller should release the reference by calling pci_dev_put() after use. Call pci_dev_put() in the error path to fix this.
CVE-2022-48887: In the Linux kernel, the following vulnerability has been resolved:  drm/vmwgfx: Remove rcu locks from user resources  User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources.  Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources.
CVE-2022-48891: In the Linux kernel, the following vulnerability has been resolved:  regulator: da9211: Use irq handler when ready  If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us.  If we enable the IRQ handler before its structures are ready, we crash.  This patch fixes:  [    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [    1.316096] Call trace: [    1.316101]  blocking_notifier_call_chain+0x20/0xa8 [    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [    1.327823]  regulator_notifier_call_chain+0x1c/0x2c [    1.327825]  da9211_irq_handler+0x68/0xf8 [    1.327829]  irq_thread+0x11c/0x234 [    1.327833]  kthread+0x13c/0x154
CVE-2023-52900: In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix general protection fault in nilfs_btree_insert()  If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails.  However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.  When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:   general protection fault, probably for non-canonical address  0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN  KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]  ...  RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]  RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]  RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238  Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89  ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c  28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02  ...  Call Trace:  <TASK>   nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]   nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147   nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101   __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991   __block_write_begin fs/buffer.c:2041 [inline]   block_write_begin+0x93/0x1e0 fs/buffer.c:2102   nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261   generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772   __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900   generic_file_write_iter+0xab/0x310 mm/filemap.c:3932   call_write_iter include/linux/fs.h:2186 [inline]   new_sync_write fs/read_write.c:491 [inline]   vfs_write+0x7dc/0xc50 fs/read_write.c:584   ksys_write+0x177/0x2a0 fs/read_write.c:637   do_syscall_x64 arch/x86/entry/common.c:50 [inline]   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80   entry_SYSCALL_64_after_hwframe+0x63/0xcd  ...  </TASK>  This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.  By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.
CVE-2023-52905: In the Linux kernel, the following vulnerability has been resolved:  octeontx2-pf: Fix resource leakage in VF driver unbind  resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue.
CVE-2023-52910: In the Linux kernel, the following vulnerability has been resolved:  iommu/iova: Fix alloc iova overflows issue  In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful.  This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node.  Example log as follows: [  223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [  223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff  2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain.  After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue.
CVE-2022-48906: In the Linux kernel, the following vulnerability has been resolved:  mptcp: Correctly set DATA_FIN timeout when number of retransmits is large  Syzkaller with UBSAN uncovered a scenario where a large number of DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN timeout calculation:  ================================================================================ UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106  ubsan_epilogue+0xb/0x5a lib/ubsan.c:151  __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330  mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]  __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445  mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528  process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307  worker_thread+0x95/0xe10 kernel/workqueue.c:2454  kthread+0x2f4/0x3b0 kernel/kthread.c:377  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295  </TASK> ================================================================================  This change limits the maximum timeout by limiting the size of the shift, which keeps all intermediate values in-bounds.
CVE-2022-48910: In the Linux kernel, the following vulnerability has been resolved:  net: ipv6: ensure we call ipv6_mc_down() at most once  There are two reasons for addrconf_notify() to be called with NETDEV_DOWN: either the network device is actually going down, or IPv6 was disabled on the interface.  If either of them stays down while the other is toggled, we repeatedly call the code for NETDEV_DOWN, including ipv6_mc_down(), while never calling the corresponding ipv6_mc_up() in between. This will cause a new entry in idev->mc_tomb to be allocated for each multicast group the interface is subscribed to, which in turn leaks one struct ifmcaddr6 per nontrivial multicast group the interface is subscribed to.  The following reproducer will leak at least $n objects:  ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); do  ip link set up eth0; ip link set down eth0 done  Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2) can also be used to create a nontrivial idev->mc_list, which will the leak objects with the right up-down-sequence.  Based on both sources for NETDEV_DOWN events the interface IPv6 state should be considered:   - not ready if the network interface is not ready OR IPv6 is disabled    for it  - ready if the network interface is ready AND IPv6 is enabled for it  The functions ipv6_mc_up() and ipv6_down() should only be run when this state changes.  Implement this by remembering when the IPv6 state is ready, and only run ipv6_mc_down() if it actually changed from ready to not ready.  The other direction (not ready -> ready) already works correctly, as:   - the interface notification triggered codepath for NETDEV_UP /    NETDEV_CHANGE returns early if ipv6 is disabled, and  - the disable_ipv6=0 triggered codepath skips fully initializing the    interface as long as addrconf_link_ready(dev) returns false  - calling ipv6_mc_up() repeatedly does not leak anything
CVE-2022-48926: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: rndis: add spinlock for rndis response list  There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list.  [  361.894299] [1:   irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0).  [  361.904380] [1:   irq/191-dwc3:16979] Call trace: [  361.904391] [1:   irq/191-dwc3:16979]  __list_add_valid+0x74/0x90 [  361.904401] [1:   irq/191-dwc3:16979]  rndis_msg_parser+0x168/0x8c0 [  361.904409] [1:   irq/191-dwc3:16979]  rndis_command_complete+0x24/0x84 [  361.904417] [1:   irq/191-dwc3:16979]  usb_gadget_giveback_request+0x20/0xe4 [  361.904426] [1:   irq/191-dwc3:16979]  dwc3_gadget_giveback+0x44/0x60 [  361.904434] [1:   irq/191-dwc3:16979]  dwc3_ep0_complete_data+0x1e8/0x3a0 [  361.904442] [1:   irq/191-dwc3:16979]  dwc3_ep0_interrupt+0x29c/0x3dc [  361.904450] [1:   irq/191-dwc3:16979]  dwc3_process_event_entry+0x78/0x6cc [  361.904457] [1:   irq/191-dwc3:16979]  dwc3_process_event_buf+0xa0/0x1ec [  361.904465] [1:   irq/191-dwc3:16979]  dwc3_thread_interrupt+0x34/0x5c
CVE-2024-6715: The Ditty  WordPress plugin before 3.1.46 re-introduced a previously fixed security issue (https://wpscan.com/vulnerability/80a9eb3a-2cb1-4844-9004-ba2554b2d46c/) in v3.1.39
CVE-2024-43887: In the Linux kernel, the following vulnerability has been resolved:  net/tcp: Disable TCP-AO static key after RCU grace period  The lifetime of TCP-AO static_key is the same as the last tcp_ao_info. On the socket destruction tcp_ao_info ceases to be with RCU grace period, while tcp-ao static branch is currently deferred destructed. The static key definition is : DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ);  which means that if RCU grace period is delayed by more than a second and tcp_ao_needed is in the process of disablement, other CPUs may yet see tcp_ao_info which atent dead, but soon-to-be. And that breaks the assumption of static_key_fast_inc_not_disabled().  See the comment near the definition: > * The caller must make sure that the static key can't get disabled while > * in this function. It doesn't patch jump labels, only adds a user to > * an already enabled static key.  Originally it was introduced in commit eb8c507296f6 ("jump_label: Prevent key->enabled int overflow"), which is needed for the atomic contexts, one of which would be the creation of a full socket from a request socket. In that atomic context, it's known by the presence of the key (md5/ao) that the static branch is already enabled. So, the ref counter for that static branch is just incremented instead of holding the proper mutex. static_key_fast_inc_not_disabled() is just a helper for such usage case. But it must not be used if the static branch could get disabled in parallel as it's not protected by jump_label_mutex and as a result, races with jump_label_update() implementation details.  Happened on netdev test-bot[1], so not a theoretical issue:  [] jump_label: Fatal kernel bug, unexpected op at tcp_inbound_hash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) size:2 type:1 [] ------------[ cut here ]------------ [] kernel BUG at arch/x86/kernel/jump_label.c:73! [] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [] CPU: 3 PID: 243 Comm: kworker/3:3 Not tainted 6.10.0-virtme #1 [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [] Workqueue: events jump_label_update_timeout [] RIP: 0010:__jump_label_patch+0x2f6/0x350 ... [] Call Trace: []  <TASK> []  arch_jump_label_transform_queue+0x6c/0x110 []  __jump_label_update+0xef/0x350 []  __static_key_slow_dec_cpuslocked.part.0+0x3c/0x60 []  jump_label_update_timeout+0x2c/0x40 []  process_one_work+0xe3b/0x1670 []  worker_thread+0x587/0xce0 []  kthread+0x28a/0x350 []  ret_from_fork+0x31/0x70 []  ret_from_fork_asm+0x1a/0x30 []  </TASK> [] Modules linked in: veth [] ---[ end trace 0000000000000000 ]--- [] RIP: 0010:__jump_label_patch+0x2f6/0x350  [1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr
CVE-2024-43892: In the Linux kernel, the following vulnerability has been resolved:  memcg: protect concurrent access to mem_cgroup_idr  Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures.  It introduced IDR to maintain the memcg ID space.  The IDR depends on external synchronization mechanisms for modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications.  However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero.  Fix that.  We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time.  These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code.  Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object.  The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success.  No evidence were found for these cases.  Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them.  So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove().  These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them.  Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.