{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-35879", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-35879" ], "published": "2024-05-19T08:35:32Z", "summary": "of: dynamic: Synchronize of_changeset_destroy() with the devlink removals", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nof: dynamic: Synchronize of_changeset_destroy() with the devlink removals\n\nIn the following sequence:\n 1) of_platform_depopulate()\n 2) of_overlay_remove()\n\nDuring the step 1, devices are destroyed and devlinks are removed.\nDuring the step 2, OF nodes are destroyed but\n__of_changeset_entry_destroy() can raise warnings related to missing\nof_node_put():\n ERROR: memory leak, expected refcount 1 instead of 2 ...\n\nIndeed, during the devlink removals performed at step 1, the removal\nitself releasing the device (and the attached of_node) is done by a job\nqueued in a workqueue and so, it is done asynchronously with respect to\nfunction calls.\nWhen the warning is present, of_node_put() will be called but wrongly\ntoo late from the workqueue job.\n\nIn order to be sure that any ongoing devlink removals are done before\nthe of_node destruction, synchronize the of_changeset_destroy() with the\ndevlink removals.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.85" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.85" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.85", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.85" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.85" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.85" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.85" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.26" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-35879" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b17411db6f5c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8917e7385346bd6584890ed362985c219fe6ae84" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable sequence is reached through local device-tree overlay teardown (driver unbind via sysfs, PCI/FPGA hot-unplug handling, DLPAR), not through any network or remote protocol input. No remote peer data reaches drivers/of/dynamic.c.\nAC:L - The devlink removal job is queued asynchronously and of_platform_depopulate() returns immediately before of_overlay_remove() runs, so the outstanding-reference condition occurs reliably (the reporter and testers hit it consistently), and the teardown can be repeated in a loop via unbind/rebind cycles.\nPR:L - No capability check guards the racy path; entry is device removal/unbind, which on embedded and hotplug-capable deployments is initiated by device events or low-privileged management paths rather than gated authentication. Choosing the higher-severity option where the privilege boundary is deployment-dependent.\nUI:N - The overlay teardown is initiated by the attacker's own action (unbind/hot-unplug) or by an autonomous device event; no separate victim needs to perform any operation.\nS:U - The corrupted objects (struct device_node, kobject refcounts, kernel heap) all live within the kernel's own security authority; no VM, IOMMU or sandbox boundary is crossed.\nC:H - When a leaked child node's parent device_node has already been freed, of_node_release()'s %pOF print dereferences the freed parent and its freed full_name pointer, rendering reclaimed heap contents into the kernel log \u2014 a use-after-free read of attacker-influenceable memory.\nI:H - The same path performs kobject_get()/refcount_inc() on the freed parent object, writing into memory that can be reclaimed by an attacker-sprayed allocation during the asynchronous workqueue window, giving a use-after-free write primitive.\nA:H - Every affected teardown permanently leaks device_node memory plus its properties, and the resulting refcount-0 nodes left in fwnode link lists and dangling parent pointers produce refcount_t warnings and freed-memory dereferences that oops (and panic under panic_on_warn); repeated hot-unplug cycles drive unbounded memory exhaustion." } } }