Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • hm. surprised there aren't idioms like copy_(to|from)_user for these kinds of kernel to userspace mappings for custom device nodes that ensure bounds are supplied...
  • There have been some V4L2 enhancements to support hardware video decoding pending a merge for a long time, they do seem to be in the mainline kernel now, I guess people didn't want to wait that long.
    by rjsw
  • And that is against a device whose BSP is actually open source and available for research!

    Now imagine the dark horrors hiding in the BSPs of other Android devices... or embedded devices in general.

    Frankly, it should be a requirement of Google's certification process that everything regarding drivers gets upstreamed into the Linux kernel. Yes, even if this adds quite a time delay to the usual hardware development process.

  • Where are the iPhone jailbreaks didn’t see anything since a long time.. what’s happening? Did I miss them or isn’t anything available? I mean props to Apple however they do it but is it a matter of time in regard to the current timeline or what is actually going on?
  • Always annoyed me how "Jailbreaks" don't get the same scrutiny as they're software vulnerabilities as they do on other platforms...
  • Exploits that can survive reboots are almost impossible these days. And a jailbreak enabling exploit now requires a whole chain of exploits which are worth significant money and also get patched as soon as they become public.

    So something like the old iphone jailbreaking scene is just impossible now.

  • Apple's security posture with lockdown mode, memory tagging, and secure allocators is significantly better than Android. You can read some about it here: https://security.apple.com/blog/memory-integrity-enforcement...
  • Do we have any evidence on how AI has affected NSO et als’ businesses? Does it render them obsolete? Or are they now superpowered?
  • Without knowing details I guess that ai is changing the game a lot and a lot of 'capital' in the form of zero days has been destroyed.

    If this is the case it's good news for everyone else besides NSO and Co

  • I would expect it to supercharge them at first and become commoditized later on.

    It is just like how a digital calculator affected the role of the human calculator, or how an automaton that can code would affect the job of a human programmer.

  • Project Zero has to report bugs to Android through the front door, and deal with Android VRP severity classification? I always assumed they could just walk over to the Android office and advocate for their bugs, face to face.
  • This assumes that Android would listen to them.
  • If they felt it was too painful to do it the "normal" way then that would probably be the next thing for Project Zero try to get fixed.
  • This is a great bug report! I am not a kernel expert by any means even though I have read some about it... 10+ years ago. And I was able to follow along and see what was going on.

    It does make me scared for what other dangers lurk since this was a really bad one and it was so little work to find.

    Also of note: so many security issues lately have been done using AI. This report makes me think two things:

    1. Expertise is still immensely valuable, the more niche, the more valuable.

    2. There are lots of niches still where AI doesn't dominate...

  • Hmmm... I'd like someone to double check my thinking here. I posted this exact prompt for gpt 5.5 xhigh:

    ```

    does this look right to you? don't do any searches or check memory, just think through first principles

    static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; }

    ```

    And it correctly identified the issue at hand, without web searches. I'd love to try something more comprehensive, e.g. shoving whole chunks of the codebase into the prompt instead of just the specific function, but it seems the latent ability to catch security exploits is there.

    So then.... I wonder how this got out in the first place. I know I'm using a toy example but would love to learn more!

  • How do you know it didn't search the web?
  • On its own we can't judge if this is a workable way to find vulns, as we don't know how many false positives you'd get if you ran it on all the code. (iow might be https://en.wikipedia.org/wiki/Base_rate_fallacy)
  • As an anecdote, I provided fragnesia.c and the subsequent proposed patch to fix the issue and while it was not able to discover an entirely new vulnerability, I think it was able to find 2 new ways of exploiting the same underlying bug.

    This is quite impressive considering I’m just a dumbass with a Claude subscription.

  • That's not really a fair test because you're leading the model pretty hard, even if the prompt doesn't specifically say there's a bug to be found. It's basically the same objections that people raised in the thread where someone claimed current models are just as good as mythos.
  • I pasted the code into claude Opus 4.7 with no internet access and just asked it to just tell me what the function did, and it explained it and also called out the bug. I did not tell it to look for bugs:

    > Observations & Potential Issues A few things worth flagging: 1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:

    ---

    70 day release cycles are very quickly not going to be fast enough to stop widespread use of exploits when you have bots able to scan every PR on every open source project as it comes out.

  • Semi-related: has the rate of published exploits picked up as if late, or is it simply the fact that there’s hype around ai as security tool (offense or defense) so it’s simply in the news more often?

    Feels like there’s something new every other day - linux, windows, mobile, various commonplace tools used by everybody, the list goes on

  • A bit of both (it finds new things and news is hyped/blown up), and a third factor is that more people are trying to find things. The authors might have been able to do this already, because you still need to have a decent understanding to get useful work out of it and verify the results, but the shiny new toy and FOMO factors make people spend more hours on it that they'd have spent doing something else otherwise

    I've seen quite a few saying that they were inspired by the previous report that is presented as "the model pointed us to it" and you get FOMO about missing out if you don't snatch bugs now as well

  • There definitely is hype around AI as a security tool right now. Someone else pointed out that the rate of CVEs has gone up, but that doesn't tell is why.

    This article doesn't mention AI helping find this bug. Seems like humans can still do that on their own.

  • I've reported a few very serious issues to vendors of widely used tools in recent weeks, and it's been even more difficult than usual to get them to be acknowledged - the teams that respond are reportedly swamped.
  • This is pure guesswork, I am not a security researcher, but my guess would be that AI is increasing the amount of low quality exploitable attack surface available, while simultaneously providing security researchers with an accelerant for their work. Which is to say, its great if you use it well and really bad if you use it poorly.
  • There are reports from people who manage security bugs in OSS that there has been a big uptick in reports: initially low quality ones that were mostly bogus, but now many more legitimate ones as well.
  • I just did some analysis on this last weekend, in 2024 there were roughly 100 CVEs published every day. In April we hit approximately 200 per day.

    Going backwards from 2023, the doubling interval for published CVEs was approximately 4 to 4 1/2 years. Since then it’s approximately two years.

    There has definitely been a rapid uptick.

  • If one reads between the lines in part 1, the code in question was introduced due to AI features and the exploit was found by humans:

    https://projectzero.google/2026/01/pixel-0-click-part-1.html

    So AI usage increases bugs and humans have to weed them out!

  • "This is notably fast given that this is the first time that an Android driver bug I reported was patched within 90 days of the vendor first learning about the vulnerability."

    This makes me feel better about Google, but also makes me kind of frightened of the rest of Android. I wonder what Apple's response time is?