{"api_version":"1","generated_at":"2026-08-30T03:24:09+00:00","cve":"CVE-2026-68228","urls":{"html":"https://cve.report/CVE-2026-68228","api":"https://cve.report/api/cve/CVE-2026-68228.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-68228","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-68228"},"summary":{"title":"media: chips-media: wave5: Move src_buf Removal to finish_encode","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: chips-media: wave5: Move src_buf Removal to finish_encode\n\nDuring encoder processing, there is a case where the IRQ response could\nreturn the buffer back to userspace via v4l2_m2m_buf_done call. In this\ntime, userspace could queue up this same buffer before start_encode removes\nthe index from the ready queue. This would then lead to a case where the\nbuffer in the ready queue could be a self loop due to the\nWRITE_ONCE(prev->next, new) call in __list_add.\n\nWhen __list_del is finally called, the loop is already made so nothing\npoints back to ready queue list head and pointers are poisoned.\n\nA buffer should not be marked as DONE before the buffer is removed from\nm2m ready queue. Move removal entirely to finish_encode.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-10 13:20:11","updated_at":"2026-08-17 05:18:25"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/f24ca8b53fe15db40957bdaa40c9aa68e1557bbe","name":"https://git.kernel.org/stable/c/f24ca8b53fe15db40957bdaa40c9aa68e1557bbe","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d681227ce43bfd74b6eb69beecd9b0bec1fd8b48","name":"https://git.kernel.org/stable/c/d681227ce43bfd74b6eb69beecd9b0bec1fd8b48","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/1ee2b2b189ddc7b23c8eee1145de42b8bd19fb06","name":"https://git.kernel.org/stable/c/1ee2b2b189ddc7b23c8eee1145de42b8bd19fb06","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/b20157147089a9c16a38c7810e2fe6f2df8e3277","name":"https://git.kernel.org/stable/c/b20157147089a9c16a38c7810e2fe6f2df8e3277","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-68228","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68228","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9707a6254a8a6b978bde811a44fe07d86c229d1c 1ee2b2b189ddc7b23c8eee1145de42b8bd19fb06 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9707a6254a8a6b978bde811a44fe07d86c229d1c f24ca8b53fe15db40957bdaa40c9aa68e1557bbe git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9707a6254a8a6b978bde811a44fe07d86c229d1c d681227ce43bfd74b6eb69beecd9b0bec1fd8b48 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9707a6254a8a6b978bde811a44fe07d86c229d1c b20157147089a9c16a38c7810e2fe6f2df8e3277 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.8","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.8 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.101 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.42 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.6 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"68228","cve":"CVE-2026-68228","epss":"0.001630000","percentile":"0.060140000","score_date":"2026-08-17","updated_at":"2026-08-18 00:11:47"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"1ee2b2b189ddc7b23c8eee1145de42b8bd19fb06","status":"affected","version":"9707a6254a8a6b978bde811a44fe07d86c229d1c","versionType":"git"},{"lessThan":"f24ca8b53fe15db40957bdaa40c9aa68e1557bbe","status":"affected","version":"9707a6254a8a6b978bde811a44fe07d86c229d1c","versionType":"git"},{"lessThan":"d681227ce43bfd74b6eb69beecd9b0bec1fd8b48","status":"affected","version":"9707a6254a8a6b978bde811a44fe07d86c229d1c","versionType":"git"},{"lessThan":"b20157147089a9c16a38c7810e2fe6f2df8e3277","status":"affected","version":"9707a6254a8a6b978bde811a44fe07d86c229d1c","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.8"},{"lessThan":"6.8","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.101","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.42","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.101","versionStartIncluding":"6.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.42","versionStartIncluding":"6.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.6","versionStartIncluding":"6.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2","versionStartIncluding":"6.8","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: chips-media: wave5: Move src_buf Removal to finish_encode\n\nDuring encoder processing, there is a case where the IRQ response could\nreturn the buffer back to userspace via v4l2_m2m_buf_done call. In this\ntime, userspace could queue up this same buffer before start_encode removes\nthe index from the ready queue. This would then lead to a case where the\nbuffer in the ready queue could be a self loop due to the\nWRITE_ONCE(prev->next, new) call in __list_add.\n\nWhen __list_del is finally called, the loop is already made so nothing\npoints back to ready queue list head and pointers are poisoned.\n\nA buffer should not be marked as DONE before the buffer is removed from\nm2m ready queue. Move removal entirely to finish_encode."}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - The flaw is reached only through V4L2 ioctls (REQBUFS/QBUF/DQBUF/STREAMON) on the local Wave5 encoder device node /dev/videoX; no network or remote input path exists.\nAC:L - Although a race, the attacker controls both sides: it drives the QBUF timing against the encode-completion IRQ and can retry on every encoded frame in a tight loop until the window is hit, so triggering is reliable.\nPR:L - An unprivileged local process that can open the encoder video node (normal on Android/embedded TI platforms where media apps hold access, or any user in the video group) can drive the full encode sequence; no capabilities are checked.\nUI:N - The attacking process performs all encode setup and buffer queueing itself; no action by another user or victim is needed.\nS:U - Corruption is confined to kernel memory managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The m2m ready-queue list corruption plus a vb2 buffer simultaneously owned by userspace and the driver yields dangling/poisoned kernel pointers and buffer state confusion that can be leveraged to read kernel memory contents.\nI:H - Doubly-linked list corruption gives an attacker-influenced write through list_add/list_del on a self-looped node, and a freed-then-reused buffer object, both of which are classic primitives for controlled kernel memory modification.\nA:H - The self-loop and subsequent __list_del leave the ready queue head detached with poisoned pointers, causing LIST_POISON dereference oops, unterminated list traversal, or a use-after-free crash that takes down the kernel."}]}],"providerMetadata":{"dateUpdated":"2026-08-17T05:01:16.349Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/1ee2b2b189ddc7b23c8eee1145de42b8bd19fb06"},{"url":"https://git.kernel.org/stable/c/f24ca8b53fe15db40957bdaa40c9aa68e1557bbe"},{"url":"https://git.kernel.org/stable/c/d681227ce43bfd74b6eb69beecd9b0bec1fd8b48"},{"url":"https://git.kernel.org/stable/c/b20157147089a9c16a38c7810e2fe6f2df8e3277"}],"title":"media: chips-media: wave5: Move src_buf Removal to finish_encode","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-68228","datePublished":"2026-08-10T12:00:50.892Z","dateReserved":"2026-07-30T09:28:09.376Z","dateUpdated":"2026-08-17T05:01:16.349Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-10 13:20:11","lastModifiedDate":"2026-08-17 05:18:25","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"68228","Ordinal":"1","Title":"media: chips-media: wave5: Move src_buf Removal to finish_encode","CVE":"CVE-2026-68228","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"68228","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: chips-media: wave5: Move src_buf Removal to finish_encode\n\nDuring encoder processing, there is a case where the IRQ response could\nreturn the buffer back to userspace via v4l2_m2m_buf_done call. In this\ntime, userspace could queue up this same buffer before start_encode removes\nthe index from the ready queue. This would then lead to a case where the\nbuffer in the ready queue could be a self loop due to the\nWRITE_ONCE(prev->next, new) call in __list_add.\n\nWhen __list_del is finally called, the loop is already made so nothing\npoints back to ready queue list head and pointers are poisoned.\n\nA buffer should not be marked as DONE before the buffer is removed from\nm2m ready queue. Move removal entirely to finish_encode.","Type":"Description","Title":"media: chips-media: wave5: Move src_buf Removal to finish_encode"}]}}}