frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

VLLM TPU: A New Unified Back End Supporting PyTorch and Jax on TPU

https://blog.vllm.ai/2025/10/16/vllm-tpu.html
1•alphabetting•50s ago•0 comments

Sqlorm – Python ORM with a focus on SQL

https://github.com/hyperflask/sqlorm
1•emixam•2m ago•0 comments

PixLab Prompt Based Photo Editor Is Now Free for All

https://editor.pixlab.io
1•symisc_devel•2m ago•0 comments

Manus 1.5

https://manus.im/blog/manus-1.5-release
1•wonderfuly•6m ago•0 comments

Lessons Learned Building Reliable Multi-Agent Systems

https://www.youtube.com/watch?v=PcQ9L0aC8ic
4•areddyfd•6m ago•2 comments

An Obscure Feature of a Long Forgotten SideProject Saved the Day

https://newbeelearn.com/blog/obscure-feature-of-forgotten-project/
2•pdyc•8m ago•0 comments

PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Compact VLM

https://huggingface.co/PaddlePaddle/PaddleOCR-VL
3•daemonologist•8m ago•1 comments

Protein phase change batteries drive innate immune signaling and cell fate

https://elifesciences.org/reviewed-preprints/107962
1•rolph•8m ago•0 comments

Hey Zuck, Remember When You Said You'd Never Again Cave to Government Pressure?

https://www.techdirt.com/2025/10/15/hey-zuck-remember-when-you-said-youd-never-again-cave-to-gove...
3•saubeidl•10m ago•1 comments

AgentZero++: Modeling Fear-Based Behavior

https://arxiv.org/abs/2510.05185
1•PaulHoule•11m ago•0 comments

AI Agent Evaluation: The Definitive Guide to Testing AI Agents

https://www.confident-ai.com/blog/definitive-ai-agent-evaluation-guide
1•dustfinger•13m ago•0 comments

Mobian Trixie Has Landed

https://blog.mobian.org/posts/2025/10/new-stable-rotating-keys/
1•fsflover•14m ago•0 comments

Deno's Other Open Source Projects

https://deno.com/blog/open-source
1•enz•15m ago•0 comments

Everything's Computer, but How?

https://howtodothingswithmemes.substack.com/p/everythings-computer-but-how
1•laurex•16m ago•0 comments

Philanthropy and Traditional Charity Are Mutually Exclusive

https://ronfriedhaber.substack.com/p/philanthropy-and-traditional-charity
1•ronfriedhaber•16m ago•1 comments

Compliance Hound – Audit for SaaS to prevent fines

https://ai-guard-copilot.lovable.app/
1•OwnerMindset•16m ago•0 comments

New maps reveal post-flood migration patterns across the US

https://theconversation.com/fema-buyouts-vs-risky-real-estate-new-maps-reveal-post-flood-migratio...
1•bikenaga•16m ago•0 comments

Open-Source Hardware: curated list of open-source ASIC tools and designs

https://github.com/aolofsson/awesome-opensource-hardware
1•imakwana•19m ago•2 comments

Show HN: iOSPreCheck – Scan Native iOS Apps for Compliance Before Submission

https://iosprecheck.com/
2•da4thrza•22m ago•1 comments

Why C variable argument functions are an abomination (and what to do about it)

https://h4x0r.org/vargs/
1•birdculture•23m ago•0 comments

Cyberforest Links

http://cyberforest.nenv.k.u-tokyo.ac.jp/
1•atjamielittle•23m ago•0 comments

Why Jamie Dimon is warning of 'cockroaches' in the US economy

https://www.cnn.com/2025/10/16/business/jamie-dimon-us-economy-cockroaches
4•koolhead17•24m ago•1 comments

Listen to a Random Forest

https://tree.fm/
1•atjamielittle•24m ago•0 comments

Show HN: Art of X: Multi-agent brainstorming

https://art-of-x.com
2•artofalex•25m ago•0 comments

Our plan to build bottom-up resistance to billionaire technology

https://gfsc.community/our-plan-to-build-bottom-up-resistance-to-billionaire-technology/
7•laurex•25m ago•1 comments

Vite+ Aims to End JavaScript's Fragmented Tooling Nightmare

https://thenewstack.io/vite-aims-to-end-javascripts-fragmented-tooling-nightmare/
1•cendenta•26m ago•1 comments

Benchmarking Postgres 17 vs. 18

https://planetscale.com/blog/benchmarking-postgres-17-vs-18
3•enz•27m ago•1 comments

Show HN: DevSecOps.Bot – A GitHub App

https://devsecops.bot
1•raushanrajjj•29m ago•0 comments

Integrate Mermaid into Astro web framework

https://realfiction.net/posts/mermaid-in-astro/
1•tom_h_h•29m ago•0 comments

Skia: Exposing Shadow Branches

https://dl.acm.org/doi/10.1145/3676641.3716273
1•blakepelton•30m ago•1 comments
Open in hackernews

A kernel stack use-after-free: Exploiting Nvidia's GPU Linux drivers

https://blog.quarkslab.com/./nvidia_gpu_kernel_vmalloc_exploit.html
166•mustache_kimono•1d ago

Comments

mustache_kimono•1d ago
Check out the disclosure timeline.

> 2025-08-11 NVIDIA reiterated the request to postpone disclosure until mid-January 2026.

> 2025-08-12 Quarkslab replied that the bugs were first reported in June 18th and mid-January was well past the standard 90 day normally agreed for coordinated disclosure and that we did not see a rationale for postponing publication by, at a minimum, 3 months. Therefore Quarkslab continued with the publication deadline set to September 23rd 2025 and offered to extend the deadline an additional 30 days provided NVIDIA gave us some insights about the full scope of affected products and if the fixes are to be released as a stand alone security fix, as opposed to rolled into a version bump that includes other code changes.

Richest corporation in the world needs 7 months to remedy? Why not 4 years?

zetanor•1d ago
> Why not 4 years?

Microsoft might hold a patent on this.

themafia•19h ago
> Richest corporation in the world

At least until the SEC starts punishing revenue inflation through self-dealing.

FridgeSeal•19h ago
I live for the day.
willis936•15h ago
Immortality hack.
pjc50•4h ago
It worked for Enron, why wouldn't it work for Nvidia? .. ah.
lenerdenator•1d ago
> Back in 2022, NVIDIA started distributing the Linux Open GPU Kernel Modules. Since 2024, using these modules is officially "the right move" for both consumer and server hardware. The driver provides multiple kernel modules, the bugs being found in nvidia.ko and nvidia-uvm.ko. They expose ioctls on device files, most of them being accessible to unprivileged users. These ioctls are meant to be used by NVIDIA's proprietary userland binaries and libraries. However, using the header files provided in the kernel modules repository as a basis, it's possible to make direct ioctl calls.

If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.

Unfortunately, so far as I'm aware, there is no way to do this and having a few people who are working against what has to be a large number of deadlines look at extremely low-level code for very sophisticated software is the only way forward for these things.

CursedSilicon•23h ago
To parody the evergreen The Onion headline

"No way to prevent this" says proprietary codebases where this always happens

tialaramex•18h ago
I've always thought the correct analogy was:

"No way to prevent this" say programmers of only languages where this regularly happens.

This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, Zig, Odin and so on but not Rust.

It's a use-after-free, a category of mistake that's impossible in true GC languages, and also impossible in safe Rust. We have known, for many years, how to not have this problem, but some people who ought to know better insist they can't stop it, exactly like America's gun violence.

jibal•15h ago
Zig pointers are non-null. Optionally null pointers must be explicitly unwrapped.
noitpmeder•15h ago
so... references and pointers?

What is my_ptr->member but unwrapping an optionally null pointer.

davemp•14h ago
It’s semantics. Zig can still have dangling references/uaf. You can do something like ‘var foo: *Bar = @intToPtr(0x00)’ but in order to “properly” use the zero address to represent state you have to use ‘var foo: ?*Bar = null’ which is a different type than ‘*Bar’ that the compiler will force you to check before accessing.

It’s the whole make it easy to write good code—not impossible to write incorrect code philosophy of the language.

pjmlp•10h ago
Thus it would not prevent a CVE like the one being discussed.
davemp•5h ago
Judging from the article, Zig would have prevented the CVE.

> This includes memory allocations of type NV01_MEMORY_DEVICELESS which are not associated with any device and therefore have the pGpu field of their corresponding MEMORY_DESCRIPTOR structure set to null

This does look like the type of null deref that Zig does prevent.

Looking at the second issue in the chain, I believe standard Zig would have prevented that as well.

The C code had an error that caused the call to free to be skipped:

    threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE);
    status = rmapiMapWithSecInfo(/*…*/); // null deref here
    threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE);
Zig’s use of ‘defer’ would ensure that free is called even if an error occurred:

    threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE);
    defer threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE);
    status = try rmapiMapWithSecInfo(/*…*/); // null deref here
pjmlp•5h ago
Assuming the user would not have forgotten to type the line with defer, and correctly as well, like all great coders.

Followed by never touching the variable ever again.

davemp•4h ago
Nothing can prevent a sufficiently belligerent programmer from writing bad code. Not even Rust—which I assume you’re advocating for without reading the greater context of this thread.
tialaramex•2h ago
We're literally in a thread about the famous Onion recurring story.

"'No Way to Prevent This,' Says Only Nation Where This Regularly Happens"

pjmlp•10h ago
Assuming they are still valid, Zig doesn't prevent use after free.
josefx•23h ago
> If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.

These bugs are in the already open sourced kernel modules, the userland components are largely irrelevant as long as an attacker can just do invoke the affected ioctl directly.

Pannoniae•15h ago
Counterargument: security by obscurity does work. The common strawman is that it doesn't, but that's when it's the only defence.

See Spectre and Meltdown - if it was easy to exploit then we would all be pwned unpatched just by running the Windows installer - just like how Windows XP machines used to do that back in the day....

If your exploit requires lots of disassembling, decrypting random ad-hoc custom crypto, and even finding what you're looking for in some random 100MB .dll, that just isn't very likely to be found except by the nationstate guys. The signal-to-noise ratio is a wonderful thing. It's much easier to hide something amongst very mundane things (most secrets are boring) than to heavily guard something and advertise "SECRETS ARE HERE". There's quite a few examples of this in various programs and web services, you obviously don't know because you didn't find it!

exe34•10h ago
I buried gold in your backyard!
Pannoniae•1h ago
Heh, good point, but it isn't really true when you invert it :) If you randomly search for stuff, you're very unlikely to find anything, only if you know what you are searching for, only then you find something...
pinaraf•23h ago
And the latest driver available for Jetson Thor doesn't have the fixes for these two CVEs because they decided to fork their own driver...
SchwKatze•17h ago
Rust would have prevented that
tombert•16h ago
You're not wrong but I think it's sort of irrelevant. Rust is cool but from my understanding, graphics card drivers are almost an entire OS in itself. I don't think Nvidia is writing a new driver for each GPU, I think they're using a core driver codebase and making relevant modifications for each card.

My point is that I suspect that the Nvidia driver is a decades-long project, and dropping everything and rewriting in Rust isn't really realistic .

fulafel•12h ago
Dropping everything is not necessary when porting to Rust, it can be done incrementally and starting with high-risk interfaces.
pjmlp•10h ago
Which is what Microsoft and Google have been doing.