Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50392 State: PUBLISHED Published: 2025-09-18T13:33:11.520Z Last Updated: 2025-09-18T13:33:11.520Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe() The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe(). References: - https://git.kernel.org/stable/c/82f7c814edda353b4781f356d3ab90e943d5eac4 - https://git.kernel.org/stable/c/574bd4d14a9297a1c69ad41001caf00fdd17d305 - https://git.kernel.org/stab
3ab90e943d5eac4 - https://git.kernel.org/stable/c/574bd4d14a9297a1c69ad41001caf00fdd17d305 - https://git.kernel.org/stable/c/156b0c19c1a44153e34cfdfa5937546a93dcb288 - https://git.kernel.org/stable/c/38eef3be38ab895959c442702864212cc3beb96c
CVE ID: CVE-2022-50393 State: PUBLISHED Published: 2025-09-18T13:33:12.247Z Last Updated: 2025-09-19T15:21:28.564Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: SDMA update use unlocked iterator SDMA update page table may be called from unlocked context, this generate below warning. Use unlocked iterator to handle this case. WARNING: CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next Call Trace: dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu] amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu
es_update+0x29c/0x870 [amdgpu] amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+0xa8/0x110 References: - https://git.kernel.org/stable/c/b892c57a3a04c8de247ab9ee08a0a8cf53290e19 - https://git.kernel.org/stable/c/4ff3d517cebe8a29b9f3c302b5292bb1ce291e00 - https://git.kernel.org/stable/c/3913f0179ba366f7d7d160c506ce00de1602bbc4
CVE ID: CVE-2022-50394 State: PUBLISHED Published: 2025-09-18T13:33:12.992Z Last Updated: 2025-09-18T13:33:12.992Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: ismt: Fix an out-of-bounds bug in ismt_access() When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt
96475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of 'data->block[0]' first. References: - https://git.kernel.org/stable/c/4a7bb1d93addb2f67e36fed00a53cb7f270d7b7a - https://git.kernel.org/stable/c/03b7ef7a6c5ca1ff5
s://git.kernel.org/stable/c/4a7bb1d93addb2f67e36fed00a53cb7f270d7b7a - https://git.kernel.org/stable/c/03b7ef7a6c5ca1ff553470166b4919db88b810f6 - https://git.kernel.org/stable/c/bfe41d966c860a8ad4c735639d616da270c92735 - https://git.kernel.org/stable/c/cdcbae2c5003747ddfd14e29db9c1d5d7e7c44dd - https://git.kernel.org/stable/c/9ac541a0898e8ec187a3fa7024b9701cffae6bf2 - https://git.kernel.org/stable/c/96c12fd0ec74641295e1c3c34dea3dce1b6c3422 - https://git.kernel.org/stable/c/a642469d464b2780a25a49b51ae56623c65eac34 - https://git.kernel.org/stable/c/233348a04becf133283f0076e20b317302de21d9 - https://git.kernel.org/stable/c/39244cc754829bf707dccd12e2ce37510f5b1f8d
CVE ID: CVE-2022-50395 State: PUBLISHED Published: 2025-09-18T13:33:13.732Z Last Updated: 2025-09-18T13:33:13.732Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks. References: - https://git.kernel.org/stable/c/9b7c44885a07c5ee7f9bf3aa3c9c72fb110c8d22 - https://git.kernel.org/stable/c/3bd737289c26be3cee4b9afaf61ef784a2af9d6e - https://git.kernel.org/stable/c/29d6c69ba4b96a1de0376e44e5f8b38b13ec8803 - https://git.kernel.org/stable/c/57e
2af9d6e - https://git.kernel.org/stable/c/29d6c69ba4b96a1de0376e44e5f8b38b13ec8803 - https://git.kernel.org/stable/c/57e49ad12f8f5df0c48e1710c54b147a05a10c32 - https://git.kernel.org/stable/c/c591c48842f08d30ec6b8416757831985ed9a315 - https://git.kernel.org/stable/c/39419ef7af0916cc3620ecf1ed42d29659109bf3
CVE ID: CVE-2022-50396 State: PUBLISHED Published: 2025-09-18T13:33:14.450Z Last Updated: 2025-09-29T11:20:30.719Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: sched: fix memory leak in tcindex_set_parms Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/
... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline] [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/r
b62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/
4 [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================== Kernel uses tcindex_change() to change an existing filter
4_after_hwframe+0x63/0xcd ==================================== Kernel uses tcindex_change() to change an existing filter properties. Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure, which triggers the above memory leak. To be more specific, there are only two source for the `old_r`, according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex
from `p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated. So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same
from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel ignores using tcindex_filter_result_init() to clear the old filter result. So only when `old_r` is retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result, which triggers the above memory leak. Considering that there already exists a tc_filter_wq workqueue to destroy the old tcindex_d ---truncated--- References: - https://git.kernel.org/stable/c/53af9c793f644d5841d84d8e0ad83bd7ab47f3e0 - https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371
ernel.org/stable/c/53af9c793f644d5841d84d8e0ad83bd7ab47f3e0 - https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b - https://git.kernel.org/stable/c/55ac68b53f1cea1926ee2313afc5d66b91daad71 - https://git.kernel.org/stable/c/7a6fb69bbcb21e9ce13bdf18c008c268874f0480 - https://git.kernel.org/stable/c/b314f6c3512108d7a656c5caf07c82d1bbbdc0f1 - https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6 - https://git.kernel.org/stable/c/6c55953e232ea668731091d111066521f3b7719b - https://git.kernel.org/stable/c/7c183dc0af472dec33d2c0786a5e356baa8cad19 - https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39 - https://git.kernel.org/stable/c/facc44
ad19 - https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39 - https://git.kernel.org/stable/c/facc4405e8b7407e03216207b1d1d640127de0c8 - https://git.kernel.org/stable/c/3abebc503a5148072052c229c6b04b329a420ecd - https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7 - https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd
CVE ID: CVE-2022-50397 State: REJECTED Published: 2025-09-18T13:33:15.161Z Last Updated: 2025-10-01T07:34:58.693Z Description: No description available.
CVE ID: CVE-2022-50398 State: PUBLISHED Published: 2025-09-18T13:33:15.877Z Last Updated: 2025-09-18T13:33:15.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: add atomic_check to bridge ops DRM commit_tails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream. There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause cr
terface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed commit_tails() called by drm_release() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dp_bridge_disable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled. This patch adds atomic_check to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crt
s down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drm_release() from calling dp_bridge_disable() so that crash at dp_bridge_disable() prevented. There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtc_state->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable. SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google
CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __cmpxchg_case_acq_32+0x14/0x2c lr : do_raw_spin_lock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0
460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dump_backtrace.part.0+0xbc/0xe4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror
e4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror_panic+0x78/0x84 do_serror+0x40/0x64 el1h_64_error_handler+0x30/0x48 el1h_64_error+0x68/0x6c __cmpxchg_case_acq_32+0x14/0x2c _raw_spin_lock_irqsave+0x38/0x4c lock_timer_base+0x40/0x78 __mod_timer+0xf4/0x25c schedule_timeout+0xd4/0xfc __wait_for_common+0xac/0x140 wait_for_completion_timeout+0x2c/0x54 dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_
mic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_client_modeset_commit_atomic+0x184/0x224 drm_client_modeset_commit_locked+0x58/0x160 drm_client_modeset_commit+0x3c/0x64 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac drm_fb_helper_set_par+0x74/0x80 drm_fb_helper_hotplug_event+0xdc/0xe0 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c drm_fb_helper_lastclose+0x20/0x2c drm_lastclose+0x44/0x6c drm_release+0x88/0xd4 __fput+0x104/0x220 ____fput+0x1c/0x28 task_work_run+0x8c/0x100 d ---truncated--- References: - https://git.kernel.org/stable/c/d106b866439c63a618d020
x1c/0x28 task_work_run+0x8c/0x100 d ---truncated--- References: - https://git.kernel.org/stable/c/d106b866439c63a618d020477bfbe7b46c759657 - https://git.kernel.org/stable/c/3a661247967a6f3c99a95a8ba4c8073c5846ea4b
CVE ID: CVE-2022-50399 State: PUBLISHED Published: 2025-09-18T13:33:16.647Z Last Updated: 2025-09-29T10:41:20.565Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: atomisp: prevent integer overflow in sh_css_set_black_frame() The "height" and "width" values come from the user so the "height * width" multiplication can overflow. References: - https://git.kernel.org/stable/c/51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 - https://git.kernel.org/stable/c/a560aeac2f2d284903b5900774765d7fc61547bc - https://git.kernel.org/stable/c/a549517e4b761f3940011db30320cb8c9badde54 - https://git.kernel.org/stable/c/3ad290194bb06979367622e473574
el.org/stable/c/a549517e4b761f3940011db30320cb8c9badde54 - https://git.kernel.org/stable/c/3ad290194bb06979367622e47357462836c1d3b4
CVE ID: CVE-2022-50400 State: PUBLISHED Published: 2025-09-18T13:58:41.397Z Last Updated: 2025-09-18T13:58:41.397Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: greybus: audio_helper: remove unused and wrong debugfs usage In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and
e ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there's no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all. References: - https://git.kernel.org/stable/c/d0febad83e29d85bb66e4f5cac0115b022403338 - https://git.kernel.org/stable/c/4dab0d27a4211a27135a6899d6c737e6e0759a11 - https://git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58 - https://git.kernel.org/stable/c/d835fa49d9589a780ff0d
git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58 - https://git.kernel.org/stable/c/d835fa49d9589a780ff0d001bb7e6323238a4afb - https://git.kernel.org/stable/c/d517cdeb904ddc0cbebcc959d43596426cac40b0
CVE ID: CVE-2022-50401 State: PUBLISHED Published: 2025-09-18T16:03:47.283Z Last Updated: 2025-09-18T16:03:47.283Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure On error situation `clp->cl_cb_conn.cb_xprt` should not be given a reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [ 72.533075] Modules l
ree. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_r
rag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c
ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0
4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] <TASK> [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ? dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? pro
ork+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [ 72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] </TASK> [ 72.564189] ---[ end trace 031117b1c72ec616 ]--- [ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ------------[ cut here ]------------ References: - https://git.kernel.org/stable/c/707bcca9616002d204091ca7c4d1d91151104332 - https://git.kernel.org/stable/c/15fc60aa5bdcf6d5f93000d3d00579fc67632ee0 - https://git.kernel.org/s
a7c4d1d91151104332 - https://git.kernel.org/stable/c/15fc60aa5bdcf6d5f93000d3d00579fc67632ee0 - https://git.kernel.org/stable/c/9b4ae8c42d2ff09ed7c5832ccce5684c55e5ed23 - https://git.kernel.org/stable/c/fddac3b4578d302ac9e51e7f03a9aae6254ae2a3 - https://git.kernel.org/stable/c/c1207219a4bfa50121c9345d5d165470d0a82531 - https://git.kernel.org/stable/c/a472f069ced8601979f53c13c0cf20236074ed46 - https://git.kernel.org/stable/c/e2f9f03e4537f3fcc8fd2bdd3248530c3477a371 - https://git.kernel.org/stable/c/d843ebd860c58a38e45527e8ec6516059f4c97f3 - https://git.kernel.org/stable/c/3bc8edc98bd43540dbe648e4ef91f443d6d20a24