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

OESA-2024-1794 (CVE-2023-52882)

Vulnerability from osv_openeuler – Published: 2024-07-05 11:07 – Updated: 2026-08-06 11:07 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: use correct buffer size when parsing configfs lists

This commit fixes uvc gadget support on 32-bit platforms.

Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for reuse") introduced a helper function __uvcg_iter_item_entries() to aid with parsing lists of items on configfs attributes stores. This function is a generalization of another very similar function, which used a stack-allocated temporary buffer of fixed size for each item in the list and used the sizeof() operator to check for potential buffer overruns. The new function was changed to allocate the now variably sized temp buffer on heap, but wasn't properly updated to also check for max buffer size using the computed size instead of sizeof() operator.

As a result, the maximum item size was 7 (plus null terminator) on 64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just barely enough, 3 is definitely too small for some of UVC configfs attributes. For example, dwFrameInteval, specified in 100ns units, usually has 6-digit item values, e.g. 166666 for 60fps.(CVE-2024-36895)

In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed.(CVE-2024-36950)

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-31.0.0.39.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-31.0.0.39.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: uvc: use correct buffer size when parsing configfs lists\r\n\r\nThis commit fixes uvc gadget support on 32-bit platforms.\r\n\r\nCommit 0df28607c5cb (\u0026quot;usb: gadget: uvc: Generalise helper functions for\nreuse\u0026quot;) introduced a helper function __uvcg_iter_item_entries() to aid\nwith parsing lists of items on configfs attributes stores. This function\nis a generalization of another very similar function, which used a\nstack-allocated temporary buffer of fixed size for each item in the list\nand used the sizeof() operator to check for potential buffer overruns.\nThe new function was changed to allocate the now variably sized temp\nbuffer on heap, but wasn\u0026apos;t properly updated to also check for max buffer\nsize using the computed size instead of sizeof() operator.\r\n\r\nAs a result, the maximum item size was 7 (plus null terminator) on\n64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just\nbarely enough, 3 is definitely too small for some of UVC configfs\nattributes. For example, dwFrameInteval, specified in 100ns units,\nusually has 6-digit item values, e.g. 166666 for 60fps.(CVE-2024-36895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: ohci: mask bus reset interrupts between ISR and bottom half\r\n\r\nIn the FireWire OHCI interrupt handler, if a bus reset interrupt has\noccurred, mask bus reset interrupts until bus_reset_work has serviced and\ncleared the interrupt.\r\n\r\nNormally, we always leave bus reset interrupts masked. We infer the bus\nreset from the self-ID interrupt that happens shortly thereafter. A\nscenario where we unmask bus reset interrupts was introduced in 2008 in\na007bb857e0b26f5d8b73c2ff90782d9c0972620: If\nOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we\nwill unmask bus reset interrupts so we can log them.\r\n\r\nirq_handler logs the bus reset interrupt. However, we can\u0026apos;t clear the bus\nreset event flag in irq_handler, because we won\u0026apos;t service the event until\nlater. irq_handler exits with the event flag still set. If the\ncorresponding interrupt is still unmasked, the first bus reset will\nusually freeze the system due to irq_handler being called again each\ntime it exits. This freeze can be reproduced by loading firewire_ohci\nwith \u0026quot;modprobe firewire_ohci debug=-1\u0026quot; (to enable all debugging output).\nApparently there are also some cases where bus_reset_work will get called\nsoon enough to clear the event, and operation will continue normally.\r\n\r\nThis freeze was first reported a few months after a007bb85 was committed,\nbut until now it was never fixed. The debug level could safely be set\nto -1 through sysfs after the module was loaded, but this would be\nineffectual in logging bus reset interrupts since they were only\nunmasked during initialization.\r\n\r\nirq_handler will now leave the event flag set but mask bus reset\ninterrupts, so irq_handler won\u0026apos;t be called again and there will be no\nfreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will\nunmask the interrupt after servicing the event, so future interrupts\nwill be caught as desired.\r\n\r\nAs a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be\nenabled through sysfs in addition to during initial module loading.\nHowever, when enabled through sysfs, logging of bus reset interrupts will\nbe effective only starting with the second bus reset, after\nbus_reset_work has executed.(CVE-2024-36950)",
  "id": "OESA-2024-1794",
  "modified": "2026-08-06T11:07:15Z",
  "published": "2024-07-05T11:07:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36950"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2023-52882",
    "CVE-2024-36895",
    "CVE-2024-36950"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.


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.