gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()
In the Linux kernel, the following vulnerability has been resolved: gpio: Fix resource leaks on errors in gpiochip_add_data_with_key() Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), `gdev->dev.release` is unset. As a result, the reference count to `gdev->dev` isn't dropped on the error handling paths. Drop the reference on errors. Also reorder the instructions to make the error handling simpler. Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.95, 6.18.22, 6.19.12
- CVEs
- CVE-2026-31732
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:19 UTC · Revision 1
Source evidence
gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()
core-osv · Original sourcePublished 1 May 2026, 14:14 UTC
In the Linux kernel, the following vulnerability has been resolved: gpio: Fix resource leaks on errors in gpiochip_add_data_with_key() Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), `gdev->dev.release` is unset. As a result, the reference count to `gdev->dev` isn't dropped on the error handling paths. Drop the reference on errors. Also reorder the instructions to make the error handling simpler. Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1.
osv:CVE-2026-31732
Kernel
Fixed versions: 6.12.95, 6.18.22, 6.19.12
Complete source record
{
"id": "0bd0ad3f44a4d181bd6cb698fba727bc61dcfdd5a401d09f19f8c9d163f7bc94",
"url": "https://osv.dev/vulnerability/CVE-2026-31732",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()",
"summary": "In the Linux kernel, the following vulnerability has been resolved: gpio: Fix resource leaks on errors in gpiochip_add_data_with_key() Since commit aab5c6f20023 (\"gpio: set device type for GPIO chips\"), `gdev->dev.release` is unset. As a result, the reference count to `gdev->dev` isn't dropped on the error handling paths. Drop the reference on errors. Also reorder the instructions to make the error handling simpler. Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1.",
"evidence": "osv:CVE-2026-31732",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.12.95",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.22",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.12",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-31732",
"aliases": [
"CVE-2026-31732"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "aab5c6f200238ac45001bec3d5494fff8438a8dc"
},
{
"fixed": "a500e1837c4266ddb05b39b3e1cc71f49a43ffa5"
},
{
"fixed": "f0cf9c7b7c281956cc0dec163132cd96f76e1d60"
},
{
"fixed": "fb4584d2b324c522404c733c65840a1a6519ada8"
},
{
"fixed": "16fdabe143fce2cbf89139677728e17e21b46c28"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31732.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.9.0"
},
{
"fixed": "6.12.95"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.22"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.12"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31732.json"
}
}
],
"modified": "2026-10-28T02:30:37.515859044Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/16fdabe143fce2cbf89139677728e17e21b46c28",
"https://git.kernel.org/stable/c/a500e1837c4266ddb05b39b3e1cc71f49a43ffa5",
"https://git.kernel.org/stable/c/f0cf9c7b7c281956cc0dec163132cd96f76e1d60",
"https://git.kernel.org/stable/c/fb4584d2b324c522404c733c65840a1a6519ada8",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31732.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-31732",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31732.json"
}
},
"related_cves": [
{
"value": "CVE-2026-31732",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504620,
"published_at": "2026-05-01T14:14:30.844+00:00"
}