net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable. On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device 2. The stack happened to contain NULL where type_name is stored
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.245, 5.15.194, 5.4.300, 6.1.154, 6.12.49, 6.16.9, 6.6.108
- CVEs
- CVE-2025-39937
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 15:57 UTC · Revision 1
Source evidence
net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
core-osv · Original sourcePublished 4 Oct 2025, 07:31 UTC
In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable. On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device 2. The stack happened to contain NULL where type_name is stored
osv:CVE-2025-39937
Kernel
Fixed versions: 5.4.300, 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9
Complete source record
{
"id": "82c55dda265bc3e324b9b2143a7de355b05ff9a8272f8b1b25c62978fadea236",
"url": "https://osv.dev/vulnerability/CVE-2025-39937",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer",
"summary": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from device property\") rfkill_find_type() gets called with the possibly uninitialized \"const char *type_name;\" local variable. On x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no \"type\" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device 2. The stack happened to contain NULL where type_name is stored",
"evidence": "osv:CVE-2025-39937",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.4.300",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.245",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.194",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.154",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.108",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.49",
"evidence": "/affected/1/ranges"
},
{
"value": "6.16.9",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-39937",
"aliases": [
"CVE-2025-39937"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "7d5e9737efda16535e5b54bd627ef4881d11d31f"
},
{
"fixed": "184f608a68f96794e8fe58cd5535014d53622cde"
},
{
"fixed": "8793e7a8e1b60131a825457174ed6398111daeb7"
},
{
"fixed": "ada2282259243387e6b6e89239aeb4897e62f051"
},
{
"fixed": "47ade5f9d70b23a119ec20b1c6504864b2543a79"
},
{
"fixed": "689aee35ce671aab752f159e5c8e66d7685e6887"
},
{
"fixed": "21ba85d9d508422ca9e6698463ff9357c928c22d"
},
{
"fixed": "21a39b958b4bcf44f7674bfbbe1bbb8cad0d842d"
},
{
"fixed": "b6f56a44e4c1014b08859dcf04ed246500e310e5"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-39937.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.6.0"
},
{
"fixed": "5.4.300"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.245"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.194"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.154"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.108"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.49"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.16.9"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-39937.json"
}
}
],
"modified": "2026-10-28T02:30:36.925441294Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/184f608a68f96794e8fe58cd5535014d53622cde",
"https://git.kernel.org/stable/c/21a39b958b4bcf44f7674bfbbe1bbb8cad0d842d",
"https://git.kernel.org/stable/c/21ba85d9d508422ca9e6698463ff9357c928c22d",
"https://git.kernel.org/stable/c/47ade5f9d70b23a119ec20b1c6504864b2543a79",
"https://git.kernel.org/stable/c/689aee35ce671aab752f159e5c8e66d7685e6887",
"https://git.kernel.org/stable/c/8793e7a8e1b60131a825457174ed6398111daeb7",
"https://git.kernel.org/stable/c/ada2282259243387e6b6e89239aeb4897e62f051",
"https://git.kernel.org/stable/c/b6f56a44e4c1014b08859dcf04ed246500e310e5",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/39xxx/CVE-2025-39937.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-39937",
"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/2025/39xxx/CVE-2025-39937.json"
}
},
"related_cves": [
{
"value": "CVE-2025-39937",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504376,
"published_at": "2025-10-04T07:31:00.879+00:00"
}