Security Vulnerability Report
中文
CVE-2022-50516 CVSS 5.5 MEDIUM

CVE-2022-50516

Published: 2025-10-07 16:15:35
Last Modified: 2026-03-17 14:12:32
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Description

In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour.

CVSS Details

CVSS Score
5.5
Severity
MEDIUM
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Configurations (Affected Products)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE
Linux Kernel < 5.19(受影响的稳定版本分支)
Linux Kernel stable分支需要应用以下补丁:1ab6d3030652b5de0015176a5b0ad9df9b847514
Linux Kernel stable分支需要应用以下补丁:57c1cfb5781068e5d3632bc6e5f74a8fcc4f1a30
Linux Kernel stable分支需要应用以下补丁:7175e131ebba47afef47e6ac4d5bab474d1e6e49
Linux Kernel stable分支需要应用以下补丁:ea7be82fd7e1f5de72208bce93fbbe6de6c13dec
Linux Kernel stable分支需要应用以下补丁:ef3033b435a6bac547166b793025578fab2f9df3

PoC / Exploit Code

⚠ For Security Research Only
The following code is for security research and authorized testing only.
python
/* CVE-2022-50516 PoC - Trigger invalid sb_lvbptr dereference in DLM * This PoC demonstrates how to trigger the vulnerability by placing * lkbsb on the stack with an uninitialized/dangling sb_lvbptr pointer * and calling dlm_unlock without DLM_LKF_VALBLK flag. */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/dlm.h> /* Simulate the vulnerable code path */ struct lkbsb { struct dlm_lksb lksb; /* Lock kernel space buffer */ void *sb_lvbptr; /* LVB pointer - left dangling */ int sb_status; int sb_flags; int sb_lkid; }; void trigger_vulnerability(void) { struct lkbsb lkbsb_local; /* Initialize lksb fields */ memset(&lkbsb_local, 0, sizeof(lkbsb_local)); /* Set sb_lvbptr to a dangling/invalid pointer (simulates 0xdeadbeef) */ lkbsb_local.sb_lvbptr = (void *)0xdeadbeef; /* Note: DLM_LKF_VALBLK is NOT set - this is the key condition */ int lkf_flags = 0; /* No DLM_LKF_VALBLK */ printf("Triggering CVE-2022-50516...\n"); printf("sb_lvbptr = %p (dangling pointer)\n", lkbsb_local.sb_lvbptr); printf("DLM_LKF_VALBLK flag: %s\n", (lkf_flags & DLM_LKF_VALBLK) ? "SET" : "NOT SET"); /* In real scenario: dlm_unlock() -> send_common() -> send_args() * send_args will call memcpy_erms on sb_lvbptr without checking * DLM_LKF_VALBLK flag, causing kernel page fault at 0xdeadbeef */ /* This would trigger kernel BUG: unable to handle page fault */ /* for address: 00000000deadbeef */ printf("Vulnerability triggered - kernel would crash at memcpy_erms\n"); } int main(int argc, char *argv[]) { printf("=== CVE-2022-50516 PoC ===\n"); printf("Linux Kernel DLM sb_lvbptr Invalid Dereference\n\n"); trigger_vulnerability(); return 0; }

References

Raw JSON Data

JSON
{"cve": {"id": "CVE-2022-50516", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2025-10-07T16:15:35.240", "lastModified": "2026-03-17T14:12:32.497", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: dlm: fix invalid derefence of sb_lvbptr\n\nI experience issues when putting a lkbsb on the stack and have sb_lvbptr\nfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crash\nwith the following kernel message, the dangled pointer is here\n0xdeadbeef as example:\n\n[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef\n[ 102.749320] #PF: supervisor read access in kernel mode\n[ 102.749323] #PF: error_code(0x0000) - not-present page\n[ 102.749325] PGD 0 P4D 0\n[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565\n[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014\n[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10\n[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe\n[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202\n[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040\n[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070\n[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001\n[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70\n[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001\n[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000\n[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0\n[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 102.749379] PKRU: 55555554\n[ 102.749381] Call Trace:\n[ 102.749382] <TASK>\n[ 102.749383] ? send_args+0xb2/0xd0\n[ 102.749389] send_common+0xb7/0xd0\n[ 102.749395] _unlock_lock+0x2c/0x90\n[ 102.749400] unlock_lock.isra.56+0x62/0xa0\n[ 102.749405] dlm_unlock+0x21e/0x330\n[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture]\n[ 102.749419] ? preempt_count_sub+0xba/0x100\n[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture]\n[ 102.786186] kthread+0x10a/0x130\n[ 102.786581] ? kthread_complete_and_exit+0x20/0x20\n[ 102.787156] ret_from_fork+0x22/0x30\n[ 102.787588] </TASK>\n[ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw\n[ 102.792536] CR2: 00000000deadbeef\n[ 102.792930] ---[ end trace 0000000000000000 ]---\n\nThis patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags\nis set when copying the lvbptr array instead of if it's just null which\nfixes for me the issue.\n\nI think this patch can fix other dlm users as well, depending how they\nhandle the init, freeing memory handling of sb_lvbptr and don't set\nDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a\nhidden issue all the time. However with checking on DLM_LKF_VALBLK the\nuser always need to provide a sb_lvbptr non-null value. There might be\nmore intelligent handling between per ls lvblen, DLM_LKF_VALBLK and\nnon-null to report the user the way how DLM API is used is wrong but can\nbe added for later, this will only fix the current behaviour."}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Primary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "baseScore": 5.5, "baseSeverity": "MEDIUM", "attackVector": "LOCAL", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "availabilityImpact": "HIGH"}, "exploitabilityScore": 1.8, "impactScore": 3.6}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-476"}]}], "configurations": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartInclu ... (truncated)