GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2023-52478 (GCVE-0-2023-52478)

Vulnerability from cvelistv5 – Published: 2024-02-29 05:43 – Updated: 2026-08-05 09:10
VLAI
Title
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
Summary
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2024-08-15 19:25 UTC
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < 44481b244fcaa2b895a53081d6204c574720c38c (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < 093af62c023537f097d2ebdfaa0bc7c1a6e874e1 (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < 28ddc1e0b898291323b62d770b1b931de131a528 (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < fd72ac9556a473fc7daf54efb6ca8a97180d621d (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < f7b2c7d9831af99369fe8ad9b2a68d78942f414e (git)
Affected: c39e3d5fc9dd3e16c6f59dd94d827540040de66d , < dac501397b9d81e4782232c39f94f4307b137452 (git)
guessed Create a notification for this product.
Linux Linux Affected: 3.19
Unaffected: 0 , < 3.19 (semver)
Unaffected: 4.14.328 , ≤ 4.14.* (semver)
Unaffected: 4.19.297 , ≤ 4.19.* (semver)
Unaffected: 5.4.259 , ≤ 5.4.* (semver)
Unaffected: 5.10.199 , ≤ 5.10.* (semver)
Unaffected: 5.15.136 , ≤ 5.15.* (semver)
Unaffected: 6.1.59 , ≤ 6.1.* (semver)
Unaffected: 6.5.8 , ≤ 6.5.* (semver)
Unaffected: 6.6 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T23:03:19.785Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-52478",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-08-15T19:25:15.460942Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-08-15T19:25:22.271Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/hid/hid-logitech-hidpp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "ca0c4cc1d215dc22ab0e738c9f017c650f3183f5",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "44481b244fcaa2b895a53081d6204c574720c38c",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "093af62c023537f097d2ebdfaa0bc7c1a6e874e1",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "28ddc1e0b898291323b62d770b1b931de131a528",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "fd72ac9556a473fc7daf54efb6ca8a97180d621d",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "f7b2c7d9831af99369fe8ad9b2a68d78942f414e",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            },
            {
              "lessThan": "dac501397b9d81e4782232c39f94f4307b137452",
              "status": "affected",
              "version": "c39e3d5fc9dd3e16c6f59dd94d827540040de66d",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/hid/hid-logitech-hidpp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.19"
            },
            {
              "lessThan": "3.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.328",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.297",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.259",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.199",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.136",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.59",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.6",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.328",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.297",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.259",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.199",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.136",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.59",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5.8",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: logitech-hidpp: Fix kernel crash on receiver USB disconnect\n\nhidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)\nraces when it races with itself.\n\nhidpp_connect_event() primarily runs from a workqueue but it also runs\non probe() and if a \"device-connected\" packet is received by the hw\nwhen the thread running hidpp_connect_event() from probe() is waiting on\nthe hw, then a second thread running hidpp_connect_event() will be\nstarted from the workqueue.\n\nThis opens the following races (note the below code is simplified):\n\n1. Retrieving + printing the protocol (harmless race):\n\n\tif (!hidpp-\u003eprotocol_major) {\n\t\thidpp_root_get_protocol_version()\n\t\thidpp-\u003eprotocol_major = response.rap.params[0];\n\t}\n\nWe can actually see this race hit in the dmesg in the abrt output\nattached to rhbz#2227968:\n\n[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\n[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\n\nTesting with extra logging added has shown that after this the 2 threads\ntake turn grabbing the hw access mutex (send_mutex) so they ping-pong\nthrough all the other TOCTOU cases managing to hit all of them:\n\n2. Updating the name to the HIDPP name (harmless race):\n\n\tif (hidpp-\u003ename == hdev-\u003ename) {\n\t\t...\n\t\thidpp-\u003ename = new_name;\n\t}\n\n3. Initializing the power_supply class for the battery (problematic!):\n\nhidpp_initialize_battery()\n{\n        if (hidpp-\u003ebattery.ps)\n                return 0;\n\n\tprobe_battery(); /* Blocks, threads take turns executing this */\n\n\thidpp-\u003ebattery.desc.properties =\n\t\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\n\n\thidpp-\u003ebattery.ps =\n\t\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\n\t\t\t\t\t   \u0026hidpp-\u003ebattery.desc, cfg);\n}\n\n4. Creating delayed input_device (potentially problematic):\n\n\tif (hidpp-\u003edelayed_input)\n\t\treturn;\n\n\thidpp-\u003edelayed_input = hidpp_allocate_input(hdev);\n\nThe really big problem here is 3. Hitting the race leads to the following\nsequence:\n\n\thidpp-\u003ebattery.desc.properties =\n\t\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\n\n\thidpp-\u003ebattery.ps =\n\t\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\n\t\t\t\t\t   \u0026hidpp-\u003ebattery.desc, cfg);\n\n\t...\n\n\thidpp-\u003ebattery.desc.properties =\n\t\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\n\n\thidpp-\u003ebattery.ps =\n\t\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\n\t\t\t\t\t   \u0026hidpp-\u003ebattery.desc, cfg);\n\nSo now we have registered 2 power supplies for the same battery,\nwhich looks a bit weird from userspace\u0027s pov but this is not even\nthe really big problem.\n\nNotice how:\n\n1. This is all devm-maganaged\n2. The hidpp-\u003ebattery.desc struct is shared between the 2 power supplies\n3. hidpp-\u003ebattery.desc.properties points to the result from the second\n   devm_kmemdup()\n\nThis causes a use after free scenario on USB disconnect of the receiver:\n1. The last registered power supply class device gets unregistered\n2. The memory from the last devm_kmemdup() call gets freed,\n   hidpp-\u003ebattery.desc.properties now points to freed memory\n3. The first registered power supply class device gets unregistered,\n   this involves sending a remove uevent to userspace which invokes\n   power_supply_uevent() to fill the uevent data\n4. power_supply_uevent() uses hidpp-\u003ebattery.desc.properties which\n   now points to freed memory leading to backtraces like this one:\n\nSep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08\n...\nSep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event\nSep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0\n...\nSep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0\nSep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0\nSep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680\nSep 22 20:01:35 eric kernel:  \n---truncated---"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:A - The logitech-hidpp driver binds Bluetooth HID++ devices and Unifying/DJ wireless children; an adjacent attacker with a malicious Logitech-compatible BT or Unifying RF device can cause probe (race) and destroy/unpair (UAF) without physical USB access.\nAC:L - A malicious HID++ device can send connect events while probe\u2019s hidpp_connect_event() blocks on hardware I/O, creating both sides of the race; the race has also been hit repeatedly in the wild with real Logitech hardware.\nPR:N - Exploitation is via wireless HID/Unifying traffic to an already-present receiver or Bluetooth adapter and requires no OS account or capabilities.\nUI:N - Pairing/connect and unpair/disconnect can be driven by the attacker\u2019s peripheral (or auto-reconnect paths) without requiring a separate victim action such as mounting a volume or confirming a prompt.\nS:U - Impact is confined to the host kernel\u2019s HID/power_supply authority; this is not a VM escape, IOMMU bypass, or other cross-boundary scope change.\nC:H - The bug is a use-after-free of battery.desc.properties consumed by power_supply_uevent(); UAF of that array can disclose freed heap contents and, via OOB property indices, adjacent kernel data into uevents.\nI:H - UAF of the properties array enables heap-spray control of property enums used in set_bit() and power_supply_attrs lookups during uevent, yielding memory-corruption primitives suitable for integrity compromise/control-flow hijacking.\nA:H - The UAF reliably causes kernel oops/page faults during power_supply_unregister on disconnect, as shown in the documented crash traces."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T09:10:08.517Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5"
        },
        {
          "url": "https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c"
        },
        {
          "url": "https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b"
        },
        {
          "url": "https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1"
        },
        {
          "url": "https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528"
        },
        {
          "url": "https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d"
        },
        {
          "url": "https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e"
        },
        {
          "url": "https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452"
        }
      ],
      "title": "HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-52478",
    "datePublished": "2024-02-29T05:43:10.698Z",
    "dateReserved": "2024-02-20T12:30:33.298Z",
    "dateUpdated": "2026-08-05T09:10:08.517Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-52478",
      "date": "2026-09-16",
      "epss": "0.00251",
      "percentile": "0.16713"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionEndExcluding\": \"4.14.328\", \"matchCriteriaId\": \"F9EC0B2A-902B-4169-85CD-C137590CC4B6\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"4.15\", \"versionEndExcluding\": \"4.19.297\", \"matchCriteriaId\": \"02978144-891F-40EF-83B8-59063740AEF6\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"4.20\", \"versionEndExcluding\": \"5.4.259\", \"matchCriteriaId\": \"E9F46843-24C9-4AC7-B6BB-1EF101D05435\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.5\", \"versionEndExcluding\": \"5.10.199\", \"matchCriteriaId\": \"8D886A8D-A6CD-44FA-ACF5-DD260ECA7A1B\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.11\", \"versionEndExcluding\": \"5.15.136\", \"matchCriteriaId\": \"B1FA5161-3AC0-44DF-B1F7-93A070F2B1E7\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.16\", \"versionEndExcluding\": \"6.1.59\", \"matchCriteriaId\": \"96EA633C-1F3E-41C5-A13A-155C55A1F273\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.2\", \"versionEndExcluding\": \"6.5.8\", \"matchCriteriaId\": \"AD4E15B4-2591-4A3A-B2A2-7FEAECD5027D\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.6:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"84267A4F-DBC2-444F-B41D-69E15E1BEC97\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.6:rc2:*:*:*:*:*:*\", \"matchCriteriaId\": \"FB440208-241C-4246-9A83-C1715C0DAA6C\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.6:rc3:*:*:*:*:*:*\", \"matchCriteriaId\": \"0DC421F1-3D5A-4BEF-BF76-4E468985D20B\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.6:rc4:*:*:*:*:*:*\", \"matchCriteriaId\": \"00AB783B-BE05-40E8-9A55-6AA457D95031\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.6:rc5:*:*:*:*:*:*\", \"matchCriteriaId\": \"E7C78D0A-C4A2-4D41-B726-8979E33AD0F9\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nHID: logitech-hidpp: Fix kernel crash on receiver USB disconnect\\n\\nhidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)\\nraces when it races with itself.\\n\\nhidpp_connect_event() primarily runs from a workqueue but it also runs\\non probe() and if a \\\"device-connected\\\" packet is received by the hw\\nwhen the thread running hidpp_connect_event() from probe() is waiting on\\nthe hw, then a second thread running hidpp_connect_event() will be\\nstarted from the workqueue.\\n\\nThis opens the following races (note the below code is simplified):\\n\\n1. Retrieving + printing the protocol (harmless race):\\n\\n\\tif (!hidpp-\u003eprotocol_major) {\\n\\t\\thidpp_root_get_protocol_version()\\n\\t\\thidpp-\u003eprotocol_major = response.rap.params[0];\\n\\t}\\n\\nWe can actually see this race hit in the dmesg in the abrt output\\nattached to rhbz#2227968:\\n\\n[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n\\nTesting with extra logging added has shown that after this the 2 threads\\ntake turn grabbing the hw access mutex (send_mutex) so they ping-pong\\nthrough all the other TOCTOU cases managing to hit all of them:\\n\\n2. Updating the name to the HIDPP name (harmless race):\\n\\n\\tif (hidpp-\u003ename == hdev-\u003ename) {\\n\\t\\t...\\n\\t\\thidpp-\u003ename = new_name;\\n\\t}\\n\\n3. Initializing the power_supply class for the battery (problematic!):\\n\\nhidpp_initialize_battery()\\n{\\n        if (hidpp-\u003ebattery.ps)\\n                return 0;\\n\\n\\tprobe_battery(); /* Blocks, threads take turns executing this */\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n}\\n\\n4. Creating delayed input_device (potentially problematic):\\n\\n\\tif (hidpp-\u003edelayed_input)\\n\\t\\treturn;\\n\\n\\thidpp-\u003edelayed_input = hidpp_allocate_input(hdev);\\n\\nThe really big problem here is 3. Hitting the race leads to the following\\nsequence:\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\n\\t...\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\nSo now we have registered 2 power supplies for the same battery,\\nwhich looks a bit weird from userspace\u0027s pov but this is not even\\nthe really big problem.\\n\\nNotice how:\\n\\n1. This is all devm-maganaged\\n2. The hidpp-\u003ebattery.desc struct is shared between the 2 power supplies\\n3. hidpp-\u003ebattery.desc.properties points to the result from the second\\n   devm_kmemdup()\\n\\nThis causes a use after free scenario on USB disconnect of the receiver:\\n1. The last registered power supply class device gets unregistered\\n2. The memory from the last devm_kmemdup() call gets freed,\\n   hidpp-\u003ebattery.desc.properties now points to freed memory\\n3. The first registered power supply class device gets unregistered,\\n   this involves sending a remove uevent to userspace which invokes\\n   power_supply_uevent() to fill the uevent data\\n4. power_supply_uevent() uses hidpp-\u003ebattery.desc.properties which\\n   now points to freed memory leading to backtraces like this one:\\n\\nSep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08\\n...\\nSep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event\\nSep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0\\n...\\nSep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0\\nSep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0\\nSep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680\\nSep 22 20:01:35 eric kernel:  \\n---truncated---\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-hidpp: soluciona el fallo del kernel en la desconexi\\u00f3n del USB del receptor hidpp_connect_event() tiene *cuatro* carreras de tiempo de verificaci\\u00f3n versus tiempo de uso (TOCTOU) cuando corre consigo mismo. hidpp_connect_event() se ejecuta principalmente desde una cola de trabajo, pero tambi\\u00e9n se ejecuta en probe() y si el hw recibe un paquete \\\"dispositivo conectado\\\" cuando el subproceso que ejecuta hidpp_connect_event() desde probe() est\\u00e1 esperando en el hw, entonces se ejecuta un segundo El hilo que ejecuta hidpp_connect_event() se iniciar\\u00e1 desde la cola de trabajo. Esto abre las siguientes carreras (tenga en cuenta que el c\\u00f3digo siguiente est\\u00e1 simplificado):1. Retrieving + printing the protocol (harmless race): if (!hidpp-\u0026gt;protocol_major) { hidpp_root_get_protocol_version() hidpp-\u0026gt;protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp-\u0026gt;name == hdev-\u0026gt;name) { ... hidpp-\u0026gt;name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp-\u0026gt;battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp-\u0026gt;delayed_input) return; hidpp-\u0026gt;delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); ... hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace\u0027s pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp-\u0026gt;battery.desc struct is shared between the 2 power supplies 3. hidpp-\u0026gt;battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp-\u0026gt;battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp-\u0026gt;battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---trun\"}]",
      "id": "CVE-2023-52478",
      "lastModified": "2025-01-10T18:27:26.213",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 4.7, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.0, \"impactScore\": 3.6}]}",
      "published": "2024-02-29T06:15:45.920",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-367\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-52478\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-02-29T06:15:45.920\",\"lastModified\":\"2026-08-04T10:18:29.253\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nHID: logitech-hidpp: Fix kernel crash on receiver USB disconnect\\n\\nhidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)\\nraces when it races with itself.\\n\\nhidpp_connect_event() primarily runs from a workqueue but it also runs\\non probe() and if a \\\"device-connected\\\" packet is received by the hw\\nwhen the thread running hidpp_connect_event() from probe() is waiting on\\nthe hw, then a second thread running hidpp_connect_event() will be\\nstarted from the workqueue.\\n\\nThis opens the following races (note the below code is simplified):\\n\\n1. Retrieving + printing the protocol (harmless race):\\n\\n\\tif (!hidpp-\u003eprotocol_major) {\\n\\t\\thidpp_root_get_protocol_version()\\n\\t\\thidpp-\u003eprotocol_major = response.rap.params[0];\\n\\t}\\n\\nWe can actually see this race hit in the dmesg in the abrt output\\nattached to rhbz#2227968:\\n\\n[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n\\nTesting with extra logging added has shown that after this the 2 threads\\ntake turn grabbing the hw access mutex (send_mutex) so they ping-pong\\nthrough all the other TOCTOU cases managing to hit all of them:\\n\\n2. Updating the name to the HIDPP name (harmless race):\\n\\n\\tif (hidpp-\u003ename == hdev-\u003ename) {\\n\\t\\t...\\n\\t\\thidpp-\u003ename = new_name;\\n\\t}\\n\\n3. Initializing the power_supply class for the battery (problematic!):\\n\\nhidpp_initialize_battery()\\n{\\n        if (hidpp-\u003ebattery.ps)\\n                return 0;\\n\\n\\tprobe_battery(); /* Blocks, threads take turns executing this */\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n}\\n\\n4. Creating delayed input_device (potentially problematic):\\n\\n\\tif (hidpp-\u003edelayed_input)\\n\\t\\treturn;\\n\\n\\thidpp-\u003edelayed_input = hidpp_allocate_input(hdev);\\n\\nThe really big problem here is 3. Hitting the race leads to the following\\nsequence:\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\n\\t...\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\nSo now we have registered 2 power supplies for the same battery,\\nwhich looks a bit weird from userspace\u0027s pov but this is not even\\nthe really big problem.\\n\\nNotice how:\\n\\n1. This is all devm-maganaged\\n2. The hidpp-\u003ebattery.desc struct is shared between the 2 power supplies\\n3. hidpp-\u003ebattery.desc.properties points to the result from the second\\n   devm_kmemdup()\\n\\nThis causes a use after free scenario on USB disconnect of the receiver:\\n1. The last registered power supply class device gets unregistered\\n2. The memory from the last devm_kmemdup() call gets freed,\\n   hidpp-\u003ebattery.desc.properties now points to freed memory\\n3. The first registered power supply class device gets unregistered,\\n   this involves sending a remove uevent to userspace which invokes\\n   power_supply_uevent() to fill the uevent data\\n4. power_supply_uevent() uses hidpp-\u003ebattery.desc.properties which\\n   now points to freed memory leading to backtraces like this one:\\n\\nSep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08\\n...\\nSep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event\\nSep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0\\n...\\nSep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0\\nSep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0\\nSep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680\\nSep 22 20:01:35 eric kernel:  \\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-hidpp: soluciona el fallo del kernel en la desconexi\u00f3n del USB del receptor hidpp_connect_event() tiene *cuatro* carreras de tiempo de verificaci\u00f3n versus tiempo de uso (TOCTOU) cuando corre consigo mismo. hidpp_connect_event() se ejecuta principalmente desde una cola de trabajo, pero tambi\u00e9n se ejecuta en probe() y si el hw recibe un paquete \\\"dispositivo conectado\\\" cuando el subproceso que ejecuta hidpp_connect_event() desde probe() est\u00e1 esperando en el hw, entonces se ejecuta un segundo El hilo que ejecuta hidpp_connect_event() se iniciar\u00e1 desde la cola de trabajo. Esto abre las siguientes carreras (tenga en cuenta que el c\u00f3digo siguiente est\u00e1 simplificado):1. Retrieving + printing the protocol (harmless race): if (!hidpp-\u0026gt;protocol_major) { hidpp_root_get_protocol_version() hidpp-\u0026gt;protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp-\u0026gt;name == hdev-\u0026gt;name) { ... hidpp-\u0026gt;name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp-\u0026gt;battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp-\u0026gt;delayed_input) return; hidpp-\u0026gt;delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); ... hidpp-\u0026gt;battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp-\u0026gt;battery.ps = devm_power_supply_register(\u0026amp;hidpp-\u0026gt;hid_dev-\u0026gt;dev, \u0026amp;hidpp-\u0026gt;battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace\u0027s pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp-\u0026gt;battery.desc struct is shared between the 2 power supplies 3. hidpp-\u0026gt;battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp-\u0026gt;battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp-\u0026gt;battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---trun\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/hid/hid-logitech-hidpp.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"44481b244fcaa2b895a53081d6204c574720c38c\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"093af62c023537f097d2ebdfaa0bc7c1a6e874e1\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"28ddc1e0b898291323b62d770b1b931de131a528\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"fd72ac9556a473fc7daf54efb6ca8a97180d621d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"f7b2c7d9831af99369fe8ad9b2a68d78942f414e\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\",\"lessThan\":\"dac501397b9d81e4782232c39f94f4307b137452\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/hid/hid-logitech-hidpp.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3.19\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"3.19\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.14.328\",\"lessThanOrEqual\":\"4.14.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.19.297\",\"lessThanOrEqual\":\"4.19.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.4.259\",\"lessThanOrEqual\":\"5.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.199\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.136\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.59\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.5.8\",\"lessThanOrEqual\":\"6.5.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":8.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"ADJACENT_NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.8,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":4.7,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2024-08-15T19:25:15.460942Z\",\"id\":\"CVE-2023-52478\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-367\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"4.14.328\",\"matchCriteriaId\":\"F9EC0B2A-902B-4169-85CD-C137590CC4B6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.15\",\"versionEndExcluding\":\"4.19.297\",\"matchCriteriaId\":\"02978144-891F-40EF-83B8-59063740AEF6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.20\",\"versionEndExcluding\":\"5.4.259\",\"matchCriteriaId\":\"E9F46843-24C9-4AC7-B6BB-1EF101D05435\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.199\",\"matchCriteriaId\":\"8D886A8D-A6CD-44FA-ACF5-DD260ECA7A1B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.136\",\"matchCriteriaId\":\"B1FA5161-3AC0-44DF-B1F7-93A070F2B1E7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.59\",\"matchCriteriaId\":\"96EA633C-1F3E-41C5-A13A-155C55A1F273\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.5.8\",\"matchCriteriaId\":\"AD4E15B4-2591-4A3A-B2A2-7FEAECD5027D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.6:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"84267A4F-DBC2-444F-B41D-69E15E1BEC97\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.6:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"FB440208-241C-4246-9A83-C1715C0DAA6C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.6:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"0DC421F1-3D5A-4BEF-BF76-4E468985D20B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.6:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"00AB783B-BE05-40E8-9A55-6AA457D95031\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.6:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"E7C78D0A-C4A2-4D41-B726-8979E33AD0F9\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-08-04T22:57:33+00:00",
      "cve": "CVE-2023-52478",
      "id": "CVE-2023-52478",
      "initial_release_date": "2023-01-01T00:00:00+00:00",
      "product_status:fixed": "429",
      "product_status:known_affected": "22",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52478.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-02T12:41:46Z",
      "cve": "CVE-2023-52478",
      "id": "CVE-2023-52478",
      "initial_release_date": "2024-03-02T05:20:46Z",
      "product_status:known_affected": "384",
      "product_status:known_not_affected": "66",
      "product_status:recommended": "978",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2023-52478",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52478.json",
      "version": "68"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T23:03:19.785Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2023-52478\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-08-15T19:25:15.460942Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-08-15T19:25:19.792Z\"}}], \"cna\": {\"title\": \"HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 8.8, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:A - The logitech-hidpp driver binds Bluetooth HID++ devices and Unifying/DJ wireless children; an adjacent attacker with a malicious Logitech-compatible BT or Unifying RF device can cause probe (race) and destroy/unpair (UAF) without physical USB access.\\nAC:L - A malicious HID++ device can send connect events while probe\\u2019s hidpp_connect_event() blocks on hardware I/O, creating both sides of the race; the race has also been hit repeatedly in the wild with real Logitech hardware.\\nPR:N - Exploitation is via wireless HID/Unifying traffic to an already-present receiver or Bluetooth adapter and requires no OS account or capabilities.\\nUI:N - Pairing/connect and unpair/disconnect can be driven by the attacker\\u2019s peripheral (or auto-reconnect paths) without requiring a separate victim action such as mounting a volume or confirming a prompt.\\nS:U - Impact is confined to the host kernel\\u2019s HID/power_supply authority; this is not a VM escape, IOMMU bypass, or other cross-boundary scope change.\\nC:H - The bug is a use-after-free of battery.desc.properties consumed by power_supply_uevent(); UAF of that array can disclose freed heap contents and, via OOB property indices, adjacent kernel data into uevents.\\nI:H - UAF of the properties array enables heap-spray control of property enums used in set_bit() and power_supply_attrs lookups during uevent, yielding memory-corruption primitives suitable for integrity compromise/control-flow hijacking.\\nA:H - The UAF reliably causes kernel oops/page faults during power_supply_unregister on disconnect, as shown in the documented crash traces.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"44481b244fcaa2b895a53081d6204c574720c38c\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"093af62c023537f097d2ebdfaa0bc7c1a6e874e1\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"28ddc1e0b898291323b62d770b1b931de131a528\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"fd72ac9556a473fc7daf54efb6ca8a97180d621d\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"f7b2c7d9831af99369fe8ad9b2a68d78942f414e\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c39e3d5fc9dd3e16c6f59dd94d827540040de66d\", \"lessThan\": \"dac501397b9d81e4782232c39f94f4307b137452\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/hid/hid-logitech-hidpp.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"3.19\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"3.19\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"4.14.328\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.14.*\"}, {\"status\": \"unaffected\", \"version\": \"4.19.297\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.19.*\"}, {\"status\": \"unaffected\", \"version\": \"5.4.259\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.4.*\"}, {\"status\": \"unaffected\", \"version\": \"5.10.199\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.10.*\"}, {\"status\": \"unaffected\", \"version\": \"5.15.136\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1.59\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.5.8\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.5.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/hid/hid-logitech-hidpp.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5\"}, {\"url\": \"https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c\"}, {\"url\": \"https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b\"}, {\"url\": \"https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1\"}, {\"url\": \"https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528\"}, {\"url\": \"https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d\"}, {\"url\": \"https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e\"}, {\"url\": \"https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nHID: logitech-hidpp: Fix kernel crash on receiver USB disconnect\\n\\nhidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)\\nraces when it races with itself.\\n\\nhidpp_connect_event() primarily runs from a workqueue but it also runs\\non probe() and if a \\\"device-connected\\\" packet is received by the hw\\nwhen the thread running hidpp_connect_event() from probe() is waiting on\\nthe hw, then a second thread running hidpp_connect_event() will be\\nstarted from the workqueue.\\n\\nThis opens the following races (note the below code is simplified):\\n\\n1. Retrieving + printing the protocol (harmless race):\\n\\n\\tif (!hidpp-\u003eprotocol_major) {\\n\\t\\thidpp_root_get_protocol_version()\\n\\t\\thidpp-\u003eprotocol_major = response.rap.params[0];\\n\\t}\\n\\nWe can actually see this race hit in the dmesg in the abrt output\\nattached to rhbz#2227968:\\n\\n[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.\\n\\nTesting with extra logging added has shown that after this the 2 threads\\ntake turn grabbing the hw access mutex (send_mutex) so they ping-pong\\nthrough all the other TOCTOU cases managing to hit all of them:\\n\\n2. Updating the name to the HIDPP name (harmless race):\\n\\n\\tif (hidpp-\u003ename == hdev-\u003ename) {\\n\\t\\t...\\n\\t\\thidpp-\u003ename = new_name;\\n\\t}\\n\\n3. Initializing the power_supply class for the battery (problematic!):\\n\\nhidpp_initialize_battery()\\n{\\n        if (hidpp-\u003ebattery.ps)\\n                return 0;\\n\\n\\tprobe_battery(); /* Blocks, threads take turns executing this */\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n}\\n\\n4. Creating delayed input_device (potentially problematic):\\n\\n\\tif (hidpp-\u003edelayed_input)\\n\\t\\treturn;\\n\\n\\thidpp-\u003edelayed_input = hidpp_allocate_input(hdev);\\n\\nThe really big problem here is 3. Hitting the race leads to the following\\nsequence:\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\n\\t...\\n\\n\\thidpp-\u003ebattery.desc.properties =\\n\\t\\tdevm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);\\n\\n\\thidpp-\u003ebattery.ps =\\n\\t\\tdevm_power_supply_register(\u0026hidpp-\u003ehid_dev-\u003edev,\\n\\t\\t\\t\\t\\t   \u0026hidpp-\u003ebattery.desc, cfg);\\n\\nSo now we have registered 2 power supplies for the same battery,\\nwhich looks a bit weird from userspace\u0027s pov but this is not even\\nthe really big problem.\\n\\nNotice how:\\n\\n1. This is all devm-maganaged\\n2. The hidpp-\u003ebattery.desc struct is shared between the 2 power supplies\\n3. hidpp-\u003ebattery.desc.properties points to the result from the second\\n   devm_kmemdup()\\n\\nThis causes a use after free scenario on USB disconnect of the receiver:\\n1. The last registered power supply class device gets unregistered\\n2. The memory from the last devm_kmemdup() call gets freed,\\n   hidpp-\u003ebattery.desc.properties now points to freed memory\\n3. The first registered power supply class device gets unregistered,\\n   this involves sending a remove uevent to userspace which invokes\\n   power_supply_uevent() to fill the uevent data\\n4. power_supply_uevent() uses hidpp-\u003ebattery.desc.properties which\\n   now points to freed memory leading to backtraces like this one:\\n\\nSep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08\\n...\\nSep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event\\nSep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0\\n...\\nSep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0\\nSep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0\\nSep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0\\nSep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680\\nSep 22 20:01:35 eric kernel:  \\n---truncated---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.14.328\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.19.297\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.4.259\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.10.199\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.136\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.59\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.5.8\", \"versionStartIncluding\": \"3.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6\", \"versionStartIncluding\": \"3.19\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T09:10:08.517Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2023-52478\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T09:10:08.517Z\", \"dateReserved\": \"2024-02-20T12:30:33.298Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-02-29T05:43:10.698Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…