Trent Novelly

I'm a very infrequent poster on any social media platform, so the chances of this getting any kind of attention are slim... But it's worth a try.

I've been investigating #CVE-2024-50302, one of the vulnerabilities purportedly used in the Cellebrite 0-day chain. (This CVE received a bit of attention due to it's reported use in the wild while being a "low scoring" CVE based on CVSS.)

The fix was simple. Just change a heap allocation call in hid_alloc_report_buf to a zero-initialized version. Cool.

However, identifying the trigger for the info leak as elluded me. I'll try to set a bit of high level background context for searching for the bug.

  • The quirks or kernel behaviors triggered by emulating an "Anton device" apparently allow uninitialized bytes allocated by the vulnerable function to be sent from the host to the device via crafted HID reports (there's actually another VID/PID that should enable the same behavior since the exact same quirk class is specified.)

  • An "Anton device" is a special kind of multitouch device, handled by the hid-multitouch driver. I'm assuming the usbhid transport driver is used since USB devices were emulated, and not some other kind (I2C, or bluetooth for instance)

  • HID reports include 'INPUT', 'OUTPUT', and 'FEATURE' requests. INPUT reports are sent from the device to the host. OUTPUT reports are sent from the host to the device. And FEATURE reports can go either direction depending on what they are used for.

    • Considering there wasn't any fix related to INPUT reports being incorrectly sent from host to device, I've focused on execution paths related to OUTPUT reports and FEATURE reports that are sent to the device via SET_REPORT (I did look into GET_REPORT paths too, but that request type is for requesting and then receiving report data, rather than sending a report)

    This is where I've hit my biggest roadblock. It seems that every execution flow for the hid-multitouch device driver that allocates a buffer with the vulnerable function ,hid_alloc_report_buf, to be used in a SET_REPORT request or passed to an OUTPUT endpoint, ends up passing the bytes allocated to the hid_output_report, which memsets the bytes to be used for the report to zero. I can't find a discrepancy in the calculation of the number of bytes to memset, and the number of bytes to send. (And if there was, that would be it's own vulnerability...)

    There are a few paths through a GET_REPORT request where hid_alloc_report_buf allocates a buffer that is attached to the USB request structure, however that buffer shouldn't be transferred to the device. That path is also not unique to the behaviors enabled by an Anton device.

    So I'm either missin the control/dataflow path that results in the uninitialized buffers getting transferred via the "send" pipes as a part of otherwise expected behavior, or there's something else going on. And if there's something else going it's hard to imagine it's not some separate bug or abusing other vulnerabilities to manipulate the kernel structures to artificially "build" an info leak path.

    That's all for now... but that is likely to be my platform activity for the year...

    Cellebrite zero-day exploit used to target phone of Serbian student activist - Amnesty International Security Lab

    Amnesty International’s Security Lab uncovers sophisticated Cellebrite zero-day exploit, impacting billions of Android devices.

    Amnesty International Security Lab
    Apr 15, 2025 at 5:02pmWeb
    Show threadity [unit X-69] - VIOLENT FUCKMay 16, 2025

    @twiddles hi! A couple of us are working on the same thing, we have a Matrix, Discord, and IRC

    Would you wanna join us ? So far we are all stuck on the same thing (personally I worked on CVE-2024-53197, another worked on CVE-2024-53104, and now we are all stuck on CVE-2024-50302)

    Show threadTrent NovellyMay 20, 2025
    @ity Hey! I'd love to join!
    Show threadity [unit X-69] - VIOLENT FUCKMay 20, 2025
    @twiddles eyyy! See https://estradiol.city/@ity/114482800282797778 ^^
    ity [unit X-69] - VIOLENT FUCK (@[email protected])

    # Searching for hackers (hacker: anyone that likes making technology do what wasn't intended) to build a community for jailbreaking MR headsets Chat anyone interested in glitching Mixed Reality headsets ? I'm trying to build a community so we can get something done, as there's a bunch of folks that wanna charge money for it and I don't really like that idea x3. The main SoC is XR2 by Qualcomm, it is an ARM SoC, and most of the headsets run very locked-down Android. The goal here is to try to jailbreak it so we can run custom, fully open source software on it, possibly even mainline drivers to Linux and run something like #postmarketos :) Unfortunately I am a systems hacker, I am hopeless when it comes to electric engineering anything, so I cannot actually pull off glitching myself. I can help with the stuff that comes after, such as mainlining drivers, though :) IRC #xrbreak on oftc Matrix: #xrbreak:itycodes.org Discord: https://discord.gg/HeDAg3Ma7A Please boost! Let's build an open and accessible community! # Any help is appreciated, no information is useless! If you would be interested in helping, we need anyone with, including BUT NOT LIMITED TO - MR headsets for testing - Electrical engineering knowledge - Ability to design or assemble PCBs - Reading ARM disassembles to try to find a glitch point or a bootrom exploit or w/e - General experience with hacking embedded devices - Experience with Linux or Android security for rooting - Anyone with info about TEE/TrustZone (kexecing mainline kernel from rooted Android) - Contacts to folks that have any of the above - Experience managing communities and setting up bridges, wikis... #jailbreaking #android #linux #hacking #xr #vr

    Mastodon Glitch Edition
    Show threadTrent NovellyMay 20, 2025
    @ity Thanks!
    Show threadZhuowei ZhangMay 17, 2025

    @twiddles @ity

    GET_REPORT request buffer shouldn’t be transferred to the device

    I was looking into it - my current theory doesn’t match the blog post:

    when processing feature report descriptors:

    later on, in hid_probe->mt_set_modes->mt_need_to_apply_feature:

    So if you set your logical_maximum to 0, the second clamp will SET_REPORT if the original value is 1, and not SET_REPORT if 0.

    Problem: the Anton Touchpad doesn’t have a maxcontacts quirk.

    My other theory was that a leaked value could result in a maxcontacts that somehow causes input_mt_init_slots to fail

    Not sure how you’d do that, though. And this doesn’t use the Anton trackpad’s quirk, either.

    Anyways, I’m probably not even going to try - for a proof of concept, I’m just going to check ABS_MT_SLOT via evtest to see if any leaked value ended up there. (I think this may be accessible on Android without root via adb shell’s getevent tool?)

    Show threadZhuowei ZhangMay 17, 2025

    @twiddles @ity I did test my HID_DG_CONTACTMAX theory by simulating a 3M 1968 touchscreen, which did have the maxcontacts quirk:

    while I haven’t tested on uninitialized memory, I did try manually sending a feature report with either 0 or 1 as HID_DG_CONTACTMAX and logical_maximum=0: if the feature report I sent had 1, I get a set report back, if the feature report I sent had 0, I do not get anything back.

    $ sudo ./uhid 0 get report id=1 rnum=0 rtype=0 returning data=0 ^C $ sudo ./uhid 1 get report id=1 rnum=0 rtype=0 returning data=1 set report

    https://github.com/worthdoingbadly/uhid-capslock-keyboard/blob/main/uhid.c

    uhid-capslock-keyboard/uhid.c at main · worthdoingbadly/uhid-capslock-keyboard

    Contribute to worthdoingbadly/uhid-capslock-keyboard development by creating an account on GitHub.

    GitHub
    Show threadTrent NovellyMay 20, 2025

    @zhuowei @ity

    I hadn't managed to identify a way to trigger that SET_REPORT in mt_set_modes. I'm curious how it handles uninitialized data.

    From manually following the execution flow, it seems that the buffer will still get handled by hid_output_report, which is partly why I didn't pursue that path too diligently.

    hid_hw_request is a wrapper for either __hid_request or in the case of the USB LL driver, usbhid_request

    When you follow the chain or wrappers to the submission function, __usbhid_submit_report, when dir==USB_DIR_OUT, hid_output_report is also called.

    Show threadTrent NovellyMay 20, 2025

    @zhuowei @ity

    When I looked into whether the output length could be manipulated in some way, I found such a possibility was found and fixed:
    https://lore.kernel.org/linux-cve-announce/2024022603-CVE-2021-46906-636c@gregkh/

    That doesn't really help us, but it was interesting.

    Making sure you're not a bot!