{"api_version":"1","generated_at":"2026-09-18T00:39:23+00:00","cve":"CVE-2026-92483","urls":{"html":"https://cve.report/CVE-2026-92483","api":"https://cve.report/api/cve/CVE-2026-92483.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-92483","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-92483"},"summary":{"title":"liveupdate: Remember FLB retrieve() status","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nliveupdate: Remember FLB retrieve() status\n\nLUO keeps track of successful retrieve attempts on an FLB. It does so\nto avoid multiple retrievals of the same FLB. Multiple retrievals cause\nproblems because once the FLB is retrieved, the serialized data\nstructures are likely freed and the FLB is likely in a very different\nstate from what the code expects.\n\nAll this works well when retrieve succeeds. When it fails,\nluo_flb_retrieve_one() returns the error immediately, without ever\nstoring anywhere that a retrieve was attempted or what its error code\nwas. If the user attempts to retrieve another file registered with the\nsame FLB, LUO will attempt to call the FLB's retrieve() callback again.\n\nThe retry is problematic for much of the same reasons listed above. The\nFLB is likely in a very different state than what the retrieve logic\nnormally expects (e.g. some KHO pages may have already been restored and\nfreed).\n\nThere is no sane way of attempting the retrieve again. Remember the\nerror retrieve returned and directly return it on a retry.\n\nThis is done by changing the retrieved bool to a retrieve_status\ninteger. A value of 0 means retrieve was never attempted, a positive\nvalue means it succeeded, and a negative value means it failed and the\nerror code is the value.\n\nThis is similar to commit f85b1c6af5bc (\"liveupdate: luo_file: remember\nretrieve() status\") which did the same for LUO files.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-17 17:17:50","updated_at":"2026-09-17 17:17:50"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/5c4a03afcb21783987ffc64562b76ddd5a21b12b","name":"https://git.kernel.org/stable/c/5c4a03afcb21783987ffc64562b76ddd5a21b12b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/908f3ea3f050b865c5c2d8c1da566185a4a3efc0","name":"https://git.kernel.org/stable/c/908f3ea3f050b865c5c2d8c1da566185a4a3efc0","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-92483","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92483","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected cab056f2aae7250af50e503b81a80dfc567a1acd 908f3ea3f050b865c5c2d8c1da566185a4a3efc0 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected cab056f2aae7250af50e503b81a80dfc567a1acd 5c4a03afcb21783987ffc64562b76ddd5a21b12b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.0","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.6 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["include/linux/liveupdate.h","kernel/liveupdate/luo_flb.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"908f3ea3f050b865c5c2d8c1da566185a4a3efc0","status":"affected","version":"cab056f2aae7250af50e503b81a80dfc567a1acd","versionType":"git"},{"lessThan":"5c4a03afcb21783987ffc64562b76ddd5a21b12b","status":"affected","version":"cab056f2aae7250af50e503b81a80dfc567a1acd","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["include/linux/liveupdate.h","kernel/liveupdate/luo_flb.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.0"},{"lessThan":"7.0","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.6","versionStartIncluding":"7.0","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"7.0","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nliveupdate: Remember FLB retrieve() status\n\nLUO keeps track of successful retrieve attempts on an FLB. It does so\nto avoid multiple retrievals of the same FLB. Multiple retrievals cause\nproblems because once the FLB is retrieved, the serialized data\nstructures are likely freed and the FLB is likely in a very different\nstate from what the code expects.\n\nAll this works well when retrieve succeeds. When it fails,\nluo_flb_retrieve_one() returns the error immediately, without ever\nstoring anywhere that a retrieve was attempted or what its error code\nwas. If the user attempts to retrieve another file registered with the\nsame FLB, LUO will attempt to call the FLB's retrieve() callback again.\n\nThe retry is problematic for much of the same reasons listed above. The\nFLB is likely in a very different state than what the retrieve logic\nnormally expects (e.g. some KHO pages may have already been restored and\nfreed).\n\nThere is no sane way of attempting the retrieve again. Remember the\nerror retrieve returned and directly return it on a retry.\n\nThis is done by changing the retrieved bool to a retrieve_status\ninteger. A value of 0 means retrieve was never attempted, a positive\nvalue means it succeeded, and a negative value means it failed and the\nerror code is the value.\n\nThis is similar to commit f85b1c6af5bc (\"liveupdate: luo_file: remember\nretrieve() status\") which did the same for LUO files."}],"providerMetadata":{"dateUpdated":"2026-09-17T16:09:59.673Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/908f3ea3f050b865c5c2d8c1da566185a4a3efc0"},{"url":"https://git.kernel.org/stable/c/5c4a03afcb21783987ffc64562b76ddd5a21b12b"}],"title":"liveupdate: Remember FLB retrieve() status","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-92483","datePublished":"2026-09-17T16:09:59.673Z","dateReserved":"2026-09-16T12:21:13.870Z","dateUpdated":"2026-09-17T16:09:59.673Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-17 17:17:50","lastModifiedDate":"2026-09-17 17:17:50","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"92483","Ordinal":"1","Title":"liveupdate: Remember FLB retrieve() status","CVE":"CVE-2026-92483","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"92483","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nliveupdate: Remember FLB retrieve() status\n\nLUO keeps track of successful retrieve attempts on an FLB. It does so\nto avoid multiple retrievals of the same FLB. Multiple retrievals cause\nproblems because once the FLB is retrieved, the serialized data\nstructures are likely freed and the FLB is likely in a very different\nstate from what the code expects.\n\nAll this works well when retrieve succeeds. When it fails,\nluo_flb_retrieve_one() returns the error immediately, without ever\nstoring anywhere that a retrieve was attempted or what its error code\nwas. If the user attempts to retrieve another file registered with the\nsame FLB, LUO will attempt to call the FLB's retrieve() callback again.\n\nThe retry is problematic for much of the same reasons listed above. The\nFLB is likely in a very different state than what the retrieve logic\nnormally expects (e.g. some KHO pages may have already been restored and\nfreed).\n\nThere is no sane way of attempting the retrieve again. Remember the\nerror retrieve returned and directly return it on a retry.\n\nThis is done by changing the retrieved bool to a retrieve_status\ninteger. A value of 0 means retrieve was never attempted, a positive\nvalue means it succeeded, and a negative value means it failed and the\nerror code is the value.\n\nThis is similar to commit f85b1c6af5bc (\"liveupdate: luo_file: remember\nretrieve() status\") which did the same for LUO files.","Type":"Description","Title":"liveupdate: Remember FLB retrieve() status"}]}}}