{"api_version":"1","generated_at":"2026-10-31T09:28:21+00:00","cve":"CVE-2026-99184","urls":{"html":"https://cve.report/CVE-2026-99184","api":"https://cve.report/api/cve/CVE-2026-99184.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-99184","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-99184"},"summary":{"title":"accel/rocket: search every core slot when a core is removed","description":"In the Linux kernel, the following vulnerability has been resolved:\n\naccel/rocket: search every core slot when a core is removed\n\nrocket_remove() decrements rdev->num_cores for each core it removes,\nwhile find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding\nthe cores in the order they were bound therefore loses the last one: by\nthe time it is removed the search range has already shrunk past its\nslot, so find_core_for_dev() returns -1 and rocket_remove() gives up\nwithout doing anything.\n\nnum_cores never reaches zero, rocket_device_fini() never runs, and the\nfile-scoped rdev keeps pointing at a device that is going away. Binding\nthe cores again starts from that stale count, because rocket_probe()\ntakes rdev->num_cores as the slot to fill. On an RK3588, which describes\nthree cores, the second round lands on slots 1, 2 and 3 while rdev->cores\nwas allocated with room for three:\n\n  rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309\n  rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309\n  rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309\n\nThe write to rdev->cores[3] is past the end of the array.\n\nNothing in tree reads the core array often enough to notice, so the\noverrun is silent today. It turned up while testing a devfreq series on\ntop of this, where a worker walks every core a few times a second, and\nUBSAN caught the first bool it read out of the overrun entry:\n\n  UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10\n  load of value 5 is not a valid value for type '_Bool'\n  Workqueue: devfreq_wq devfreq_monitor\n\nRecord how many slots were allocated and search all of them. Every core\nis then found on removal, num_cores reaches zero, the device is torn down\nand a later bind starts from a clean rdev.\n\nThis does not make unbinding a single core out of several work. probe\nstill takes num_cores as the slot to fill, so rebinding one core while\nits siblings stay bound would write over a slot that is already in use,\nand rocket_open() still reaches for cores[0] whether or not anything is\nthere. Both of those want more thought than a fix should carry.\n\nFound by unbinding and rebinding all three cores on an Orange Pi 5 Plus.\nWith this applied, 25 unbind/rebind rounds and 5 module unload/reload\nrounds run clean there: the cores land in slots 0, 1 and 2 every time,\nwhichever order they are bound in, and the shared supply goes back to a\nsingle user after each round.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-28 11:17:39","updated_at":"2026-10-28 11:17:39"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/5078c91f5c84bb383d0a10ed39856f98575e39cf","name":"https://git.kernel.org/stable/c/5078c91f5c84bb383d0a10ed39856f98575e39cf","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6eff1d69dae808a1518aee5a58d0853a8db3f1be","name":"https://git.kernel.org/stable/c/6eff1d69dae808a1518aee5a58d0853a8db3f1be","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/134451cf95cb6aa04b725fbfa04e878d072756f5","name":"https://git.kernel.org/stable/c/134451cf95cb6aa04b725fbfa04e878d072756f5","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-99184","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99184","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected ed98261b41687323ffa02ca20fef1e60b38fd1aa 5078c91f5c84bb383d0a10ed39856f98575e39cf git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected ed98261b41687323ffa02ca20fef1e60b38fd1aa 134451cf95cb6aa04b725fbfa04e878d072756f5 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected ed98261b41687323ffa02ca20fef1e60b38fd1aa 6eff1d69dae808a1518aee5a58d0853a8db3f1be git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.18","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.59 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.13 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * 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":["drivers/accel/rocket/rocket_device.c","drivers/accel/rocket/rocket_device.h","drivers/accel/rocket/rocket_drv.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"5078c91f5c84bb383d0a10ed39856f98575e39cf","status":"affected","version":"ed98261b41687323ffa02ca20fef1e60b38fd1aa","versionType":"git"},{"lessThan":"134451cf95cb6aa04b725fbfa04e878d072756f5","status":"affected","version":"ed98261b41687323ffa02ca20fef1e60b38fd1aa","versionType":"git"},{"lessThan":"6eff1d69dae808a1518aee5a58d0853a8db3f1be","status":"affected","version":"ed98261b41687323ffa02ca20fef1e60b38fd1aa","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/accel/rocket/rocket_device.c","drivers/accel/rocket/rocket_device.h","drivers/accel/rocket/rocket_drv.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.18"},{"lessThan":"6.18","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.59","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.13","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.59","versionStartIncluding":"6.18","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.13","versionStartIncluding":"6.18","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"6.18","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\naccel/rocket: search every core slot when a core is removed\n\nrocket_remove() decrements rdev->num_cores for each core it removes,\nwhile find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding\nthe cores in the order they were bound therefore loses the last one: by\nthe time it is removed the search range has already shrunk past its\nslot, so find_core_for_dev() returns -1 and rocket_remove() gives up\nwithout doing anything.\n\nnum_cores never reaches zero, rocket_device_fini() never runs, and the\nfile-scoped rdev keeps pointing at a device that is going away. Binding\nthe cores again starts from that stale count, because rocket_probe()\ntakes rdev->num_cores as the slot to fill. On an RK3588, which describes\nthree cores, the second round lands on slots 1, 2 and 3 while rdev->cores\nwas allocated with room for three:\n\n  rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309\n  rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309\n  rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309\n\nThe write to rdev->cores[3] is past the end of the array.\n\nNothing in tree reads the core array often enough to notice, so the\noverrun is silent today. It turned up while testing a devfreq series on\ntop of this, where a worker walks every core a few times a second, and\nUBSAN caught the first bool it read out of the overrun entry:\n\n  UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10\n  load of value 5 is not a valid value for type '_Bool'\n  Workqueue: devfreq_wq devfreq_monitor\n\nRecord how many slots were allocated and search all of them. Every core\nis then found on removal, num_cores reaches zero, the device is torn down\nand a later bind starts from a clean rdev.\n\nThis does not make unbinding a single core out of several work. probe\nstill takes num_cores as the slot to fill, so rebinding one core while\nits siblings stay bound would write over a slot that is already in use,\nand rocket_open() still reaches for cores[0] whether or not anything is\nthere. Both of those want more thought than a fix should carry.\n\nFound by unbinding and rebinding all three cores on an Orange Pi 5 Plus.\nWith this applied, 25 unbind/rebind rounds and 5 module unload/reload\nrounds run clean there: the cores land in slots 0, 1 and 2 every time,\nwhichever order they are bound in, and the shared supply goes back to a\nsingle user after each round."}],"providerMetadata":{"dateUpdated":"2026-10-28T10:35:42.469Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/5078c91f5c84bb383d0a10ed39856f98575e39cf"},{"url":"https://git.kernel.org/stable/c/134451cf95cb6aa04b725fbfa04e878d072756f5"},{"url":"https://git.kernel.org/stable/c/6eff1d69dae808a1518aee5a58d0853a8db3f1be"}],"title":"accel/rocket: search every core slot when a core is removed","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-99184","datePublished":"2026-10-28T10:35:42.469Z","dateReserved":"2026-09-25T10:25:14.399Z","dateUpdated":"2026-10-28T10:35:42.469Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-28 11:17:39","lastModifiedDate":"2026-10-28 11:17:39","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"99184","Ordinal":"1","Title":"accel/rocket: search every core slot when a core is removed","CVE":"CVE-2026-99184","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"99184","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\naccel/rocket: search every core slot when a core is removed\n\nrocket_remove() decrements rdev->num_cores for each core it removes,\nwhile find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding\nthe cores in the order they were bound therefore loses the last one: by\nthe time it is removed the search range has already shrunk past its\nslot, so find_core_for_dev() returns -1 and rocket_remove() gives up\nwithout doing anything.\n\nnum_cores never reaches zero, rocket_device_fini() never runs, and the\nfile-scoped rdev keeps pointing at a device that is going away. Binding\nthe cores again starts from that stale count, because rocket_probe()\ntakes rdev->num_cores as the slot to fill. On an RK3588, which describes\nthree cores, the second round lands on slots 1, 2 and 3 while rdev->cores\nwas allocated with room for three:\n\n  rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309\n  rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309\n  rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309\n\nThe write to rdev->cores[3] is past the end of the array.\n\nNothing in tree reads the core array often enough to notice, so the\noverrun is silent today. It turned up while testing a devfreq series on\ntop of this, where a worker walks every core a few times a second, and\nUBSAN caught the first bool it read out of the overrun entry:\n\n  UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10\n  load of value 5 is not a valid value for type '_Bool'\n  Workqueue: devfreq_wq devfreq_monitor\n\nRecord how many slots were allocated and search all of them. Every core\nis then found on removal, num_cores reaches zero, the device is torn down\nand a later bind starts from a clean rdev.\n\nThis does not make unbinding a single core out of several work. probe\nstill takes num_cores as the slot to fill, so rebinding one core while\nits siblings stay bound would write over a slot that is already in use,\nand rocket_open() still reaches for cores[0] whether or not anything is\nthere. Both of those want more thought than a fix should carry.\n\nFound by unbinding and rebinding all three cores on an Orange Pi 5 Plus.\nWith this applied, 25 unbind/rebind rounds and 5 module unload/reload\nrounds run clean there: the cores land in slots 0, 1 and 2 every time,\nwhichever order they are bound in, and the shared supply goes back to a\nsingle user after each round.","Type":"Description","Title":"accel/rocket: search every core slot when a core is removed"}]}}}