{"api_version":"1","generated_at":"2026-04-26T04:53:16+00:00","cve":"CVE-2026-31614","urls":{"html":"https://cve.report/CVE-2026-31614","api":"https://cve.report/api/cve/CVE-2026-31614.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-31614","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-31614"},"summary":{"title":"smb: client: fix off-by-8 bounds check in check_wsl_eas()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix off-by-8 bounds check in check_wsl_eas()\n\nThe bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA\nname and value, but ea_data sits at offset sizeof(struct\nsmb2_file_full_ea_info) = 8 from ea, not at offset 0.  The strncmp()\nlater reads ea->ea_data[0..nlen-1] and the value bytes follow at\nea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1\n+ vlen.  Isn't pointer math fun?\n\nThe earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the\n8-byte header is in bounds, but since the last EA is placed within 8\nbytes of the end of the response, the name and value bytes are read past\nthe end of iov.\n\nFix this mess all up by using ea->ea_data as the base for the bounds\ncheck.\n\nAn \"untrusted\" server can use this to leak up to 8 bytes of kernel heap\ninto the EA name comparison and influence which WSL xattr the data is\ninterpreted as.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-04-24 15:16:40","updated_at":"2026-04-24 17:51:40"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/5cc0574c84aa73946ade587c41e81757b8b01cb5","name":"https://git.kernel.org/stable/c/5cc0574c84aa73946ade587c41e81757b8b01cb5","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18","name":"https://git.kernel.org/stable/c/ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a893f1757d9a4009e4a8d7ceb2312142fe29cea4","name":"https://git.kernel.org/stable/c/a893f1757d9a4009e4a8d7ceb2312142fe29cea4","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/b2b76d09a64c538c57006180103fc1841e8cfa66","name":"https://git.kernel.org/stable/c/b2b76d09a64c538c57006180103fc1841e8cfa66","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-31614","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31614","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 5cc0574c84aa73946ade587c41e81757b8b01cb5 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 b2b76d09a64c538c57006180103fc1841e8cfa66 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 a893f1757d9a4009e4a8d7ceb2312142fe29cea4 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.83 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.24 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19.14 6.19.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0.1 7.0.* semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"31614","cve":"CVE-2026-31614","epss":"0.000180000","percentile":"0.046210000","score_date":"2026-04-25","updated_at":"2026-04-26 00:00:20"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/smb/client/smb2inode.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"5cc0574c84aa73946ade587c41e81757b8b01cb5","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"b2b76d09a64c538c57006180103fc1841e8cfa66","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"a893f1757d9a4009e4a8d7ceb2312142fe29cea4","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/smb/client/smb2inode.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.83","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.24","versionType":"semver"},{"lessThanOrEqual":"6.19.*","status":"unaffected","version":"6.19.14","versionType":"semver"},{"lessThanOrEqual":"7.0.*","status":"unaffected","version":"7.0.1","versionType":"semver"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.83","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.24","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.19.14","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0.1","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix off-by-8 bounds check in check_wsl_eas()\n\nThe bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA\nname and value, but ea_data sits at offset sizeof(struct\nsmb2_file_full_ea_info) = 8 from ea, not at offset 0.  The strncmp()\nlater reads ea->ea_data[0..nlen-1] and the value bytes follow at\nea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1\n+ vlen.  Isn't pointer math fun?\n\nThe earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the\n8-byte header is in bounds, but since the last EA is placed within 8\nbytes of the end of the response, the name and value bytes are read past\nthe end of iov.\n\nFix this mess all up by using ea->ea_data as the base for the bounds\ncheck.\n\nAn \"untrusted\" server can use this to leak up to 8 bytes of kernel heap\ninto the EA name comparison and influence which WSL xattr the data is\ninterpreted as."}],"providerMetadata":{"dateUpdated":"2026-04-24T14:42:34.153Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/5cc0574c84aa73946ade587c41e81757b8b01cb5"},{"url":"https://git.kernel.org/stable/c/b2b76d09a64c538c57006180103fc1841e8cfa66"},{"url":"https://git.kernel.org/stable/c/ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18"},{"url":"https://git.kernel.org/stable/c/a893f1757d9a4009e4a8d7ceb2312142fe29cea4"}],"title":"smb: client: fix off-by-8 bounds check in check_wsl_eas()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-31614","datePublished":"2026-04-24T14:42:34.153Z","dateReserved":"2026-03-09T15:48:24.123Z","dateUpdated":"2026-04-24T14:42:34.153Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-04-24 15:16:40","lastModifiedDate":"2026-04-24 17:51:40","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"31614","Ordinal":"1","Title":"smb: client: fix off-by-8 bounds check in check_wsl_eas()","CVE":"CVE-2026-31614","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"31614","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix off-by-8 bounds check in check_wsl_eas()\n\nThe bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA\nname and value, but ea_data sits at offset sizeof(struct\nsmb2_file_full_ea_info) = 8 from ea, not at offset 0.  The strncmp()\nlater reads ea->ea_data[0..nlen-1] and the value bytes follow at\nea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1\n+ vlen.  Isn't pointer math fun?\n\nThe earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the\n8-byte header is in bounds, but since the last EA is placed within 8\nbytes of the end of the response, the name and value bytes are read past\nthe end of iov.\n\nFix this mess all up by using ea->ea_data as the base for the bounds\ncheck.\n\nAn \"untrusted\" server can use this to leak up to 8 bytes of kernel heap\ninto the EA name comparison and influence which WSL xattr the data is\ninterpreted as.","Type":"Description","Title":"smb: client: fix off-by-8 bounds check in check_wsl_eas()"}]}}}