Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-day CSS: CVE-2026-2441 exists in the wild

chromereleases.googleblog.com

Post reply on HN
Print view View original

221–230 of 242 posts

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#221

Post by astrobe_ »

iririririr wrote: post #86
astrobe_ wrote: post #37

This doesn't affect the many browsers based on Chromium?

why on earth would you even assume somthing like this? honestly curious. do you think "based on chrome" means they forked the engine and not just "applied some UI skin"?

The CVE itself only lists Chrome as the "affected software configuration", and I missed the line saying other browsers in the blog post, so I had a slight doubt. Other projects could use a drop-in replacement lib for the CSS, that's something one sees sometimes for other things (e.g. crypto libs - some projects have compile-time options ready for this).

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#222

Post by zbentley »

pjmlp wrote: post #198
StilesCrisis wrote: post #113

Earlier quoted context omitted.

I don't think Go was ever planned to completely overtake C++. It is still a garbage collected language at the end of the day.

Many people enjoy playing games, and video productions, written in a garbage collected C++ engine. Go's main issue is its language design approach.

Say more?

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#223

Post by ceteia »

kibwen wrote: post #207
ceteia wrote: post #165

Earlier quoted context omitted.

People also write Rust code that is not memory-safe. https://materialize.com/blog/rust-concurrency-bug-unbounded-...

The vast majority of Rust code out there doesn't use the `unsafe` keyword at all, and the vastly smaller amount of unsafe code that exists allows for focused and precise testing and verification. You really have no idea what you're talking about if you're trying to say that Rust is anywhere in the ballpark of C or C++ here.

Indeed, unsafe Rust is overall more difficult than C++, like one speaker at a Rust conference claimed: https://lucumr.pocoo.org/2022/1/30/unsafe-rust/

And you are not being honest nor accurate here.

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#225

Post by 3oil3 »

capitainenemo wrote: post #214
3oil3 wrote: post #187

Earlier quoted context omitted.

I just want Firefox's search box to be on the top of the window so I don't have to bend my neck when I'm surfing in bed... I don't use it just for that.

If you're talking about url/search bar at the bottom on mobile, that's customisable - actually they ask you which you prefer when you install it, but you can change it at any time in settings. (personally I prefer all that stuff at the bottom since it's more conveniently where all my other phone nav is, and visibility fits in well with how I scroll)

I mean on the computer, and I haven't found a way to have it at the top.

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#227

Post by joshuamorton »

ceteia wrote: post #171
joshuamorton wrote: post #170

Earlier quoted context omitted.

But not "routinely".

How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe. https://github.com/trifectatechfoundation/sudo-rs https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their uns…

> but its code has lots of unsafe.

And every instance of unsafe that I could find (except one, in test-only code) was a call to libc with a clarifying comment on why this particular use was safe. That is, all (or at least, all of it that I could find) was wrapping an unsafe API with documented (and usually straightforward and local) invariants that maintain safety, such that the calling code is safe.

I'd say that the fact that miri's trophy-shelf[0] has 39 entries and is 7 years old and still regularly updated is a pretty good indicator that memory bugs are sufficiently rare in rust so as to be notable. That is the opposite of "regular"

[0]: https://github.com/rust-lang/miri/blame/master/README.md

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#228

Post by ceteia »

joshuamorton wrote: post #227
ceteia wrote: post #171

Earlier quoted context omitted.

How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe. https://github.com/trifectatechfoundation/sudo-rs https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their uns…

> but its code has lots of unsafe. And every instance of unsafe that I could find (except one, in test-only code) was a call to libc with a clarifying comment on why this particular use was safe. That is, all (or at least, all of it that I could find) was wrapping an unsafe API with documented (and usually straightforward and local) invariants that maintain safety, such that the calling code is safe. I'd say that the…

[flagged]

Re: Zero-day CSS: CVE-2026-2441 exists in the wild

#230

Post by joshuamorton »

ceteia wrote: post #228
joshuamorton wrote: post #227

Earlier quoted context omitted.

> but its code has lots of unsafe. And every instance of unsafe that I could find (except one, in test-only code) was a call to libc with a clarifying comment on why this particular use was safe. That is, all (or at least, all of it that I could find) was wrapping an unsafe API with documented (and usually straightforward and local) invariants that maintain safety, such that the calling code is safe. I'd say that the…

[flagged]

> A comment does not automatically make code safe. What even is that argument? There have directly been examples of Rust code with SAFETY comments that later were found to be memory unsafe.

I did not make this argument. I encourage you to reread my comment and do so with the HN guidelines in mind!

Post reply on HN