In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Fix double-free of fwnode in i2c_unregister_device()
Before commit df6d7277e552 ("i2c: core: Do not dereference fwnode in struct
device"), i2c_unregister_device() only called fwnode_handle_put() on
of_node-s in the form of calling of_node_put(client->dev.of_node).
But after this commit the i2c_client's fwnode now unconditionally gets
fwnode_handle_put() on it.
When the i2c_client has no primary (ACPI / OF) fwnode but it does have
a software fwnode, the software-node will be the primary node and
fwnode_handle_put() will put() it.
But for the software fwnode device_remove_software_node() will also put()
it leading to a double free:
[ 82.665598] ------------[ cut here ]------------
[ 82.665609] refcount_t: underflow; use-after-free.
[ 82.665808] WARNING: CPU: 3 PID: 1502 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x11
...
[ 82.666830] RIP: 0010:refcount_warn_saturate+0xba/0x110
...
[ 82.666962] <TASK>
[ 82.666971] i2c_unregister_device+0x60/0x90
Fix this by not calling fwnode_handle_put() when the primary fwnode is
a software-node.
i2c: core: Fix double-free of fwnode in i2c_unregister_device()
Before commit df6d7277e552 ("i2c: core: Do not dereference fwnode in struct
device"), i2c_unregister_device() only called fwnode_handle_put() on
of_node-s in the form of calling of_node_put(client->dev.of_node).
But after this commit the i2c_client's fwnode now unconditionally gets
fwnode_handle_put() on it.
When the i2c_client has no primary (ACPI / OF) fwnode but it does have
a software fwnode, the software-node will be the primary node and
fwnode_handle_put() will put() it.
But for the software fwnode device_remove_software_node() will also put()
it leading to a double free:
[ 82.665598] ------------[ cut here ]------------
[ 82.665609] refcount_t: underflow; use-after-free.
[ 82.665808] WARNING: CPU: 3 PID: 1502 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x11
...
[ 82.666830] RIP: 0010:refcount_warn_saturate+0xba/0x110
...
[ 82.666962] <TASK>
[ 82.666971] i2c_unregister_device+0x60/0x90
Fix this by not calling fwnode_handle_put() when the primary fwnode is
a software-node.
Metrics
Affected Vendors & Products
References
History
Fri, 05 Sep 2025 14:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Vendors & Products |
Linux
Linux linux Kernel |
Fri, 05 Sep 2025 00:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Thu, 04 Sep 2025 15:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | In the Linux kernel, the following vulnerability has been resolved: i2c: core: Fix double-free of fwnode in i2c_unregister_device() Before commit df6d7277e552 ("i2c: core: Do not dereference fwnode in struct device"), i2c_unregister_device() only called fwnode_handle_put() on of_node-s in the form of calling of_node_put(client->dev.of_node). But after this commit the i2c_client's fwnode now unconditionally gets fwnode_handle_put() on it. When the i2c_client has no primary (ACPI / OF) fwnode but it does have a software fwnode, the software-node will be the primary node and fwnode_handle_put() will put() it. But for the software fwnode device_remove_software_node() will also put() it leading to a double free: [ 82.665598] ------------[ cut here ]------------ [ 82.665609] refcount_t: underflow; use-after-free. [ 82.665808] WARNING: CPU: 3 PID: 1502 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x11 ... [ 82.666830] RIP: 0010:refcount_warn_saturate+0xba/0x110 ... [ 82.666962] <TASK> [ 82.666971] i2c_unregister_device+0x60/0x90 Fix this by not calling fwnode_handle_put() when the primary fwnode is a software-node. | |
Title | i2c: core: Fix double-free of fwnode in i2c_unregister_device() | |
References |
|

Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-09-04T15:32:37.403Z
Reserved: 2025-04-16T04:51:24.031Z
Link: CVE-2025-38682

No data.

Status : Awaiting Analysis
Published: 2025-09-04T16:15:35.910
Modified: 2025-09-05T17:47:24.833
Link: CVE-2025-38682


Updated: 2025-09-05T14:02:52Z