&gt; I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.At this point you just require every compound infix expression to be parenthesised, the terseness isn&#x27;t worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).And then you do automatic parens insertion in the LSP, so you write<pre><code> a - b - c
</code></pre>
and when you save the lsp fixed it up to<pre><code> (a - b) - c</code></pre>

I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.<pre><code> a - b - c
</code></pre>
is order dependent, even if its deterministic and knowable. When I’m scanning the code to look for a pesky bug, I don’t wanna have to take extra seconds to convince myself that it’s doing what I expect. It steals time and my limited attention from more interesting sections of code.

Non-mixed always goes strictly left to right, regardless of the operator, which I haven&#x27;t seen anywhere near as much struggling with.But yes, I personally parenthesize `a-b-c` explicitly, because it&#x27;s not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that&#x27;s an excellent tradeoff imo, and is a trivial pattern to follow.(Associative operators are fine, obviously)

Didn&#x27;t you just suffer from the same trap the parent was trying to avoid?

- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.

Smalltalk didn&#x27;t have math operator precedence, and I thought it was very annoying but I&#x27;ve come to believe it was a good idea.

IIRC several industry and government coding standards don&#x27;t permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.

Nice: <a href="https:&#x2F;&#x2F;tutorial.ponylang.io&#x2F;expressions&#x2F;ops#precedence" rel="nofollow">https:&#x2F;&#x2F;tutorial.ponylang.io&#x2F;expressions&#x2F;ops#precedence</a>Yeah that&#x27;s pretty much exactly what I do by hand. I should really give Pony a try some time... there&#x27;s a lot of stuff in it that I like.

That&#x27;s what pony did also. Operator preceding rules are too arcane, such as the need for manual memory management.

<pre><code> - args-&gt;endp - args-&gt;begin_argv + consume);
 + args-&gt;endp - (args-&gt;begin_argv + consume));
</code></pre>
tbh I&#x27;ve considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least.I&#x27;ve seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it really doesn&#x27;t seem worth it (in most code) for the extremely minor character savings.

Nice to randomly encounter our own work here.Check out our blog post for a fun walkthrough: <a href="https:&#x2F;&#x2F;blog.calif.io&#x2F;p&#x2F;cve-2026-7270-how-i-get-root-on-freebsd" rel="nofollow">https:&#x2F;&#x2F;blog.calif.io&#x2F;p&#x2F;cve-2026-7270-how-i-get-root-on-free...</a>AI-generated working exploit, write-up and prompts: <a href="https:&#x2F;&#x2F;github.com&#x2F;califio&#x2F;publications&#x2F;tree&#x2F;main&#x2F;MADBugs&#x2F;freebsd-CVE-2026-7270" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;califio&#x2F;publications&#x2F;tree&#x2F;main&#x2F;MADBugs&#x2F;fr...</a>

Everyone&#x27;s got a list of people they&#x27;re proud to have worked with, you&#x27;re on mine.

You&#x27;re always super kind to me :)

Calif is just killing it these past couple months. Reminder that Calif is Thai Duong&#x27;s new firm.

-p8 is the current patch level for 15.0-RELEASE so if people have been keeping on top of patching this is already two reboots in the past.

Or in other words, the response is well-coordinated so cperciva&#x27;s bragging is justified, isn&#x27;t it?

He was talking about managing disclosure and patch flow, and you&#x27;re just taking it as an opportunity to dunk on him.

I think cperciva may have been a touch overenthusiastic, but surely this is in fact proving his point? His claim was, as you note before trying to ignore it, about coordination. When one of the recent Linux LPEs broke, the fix wasn&#x27;t in distro packages yet; there was a vulnerability that users couldn&#x27;t practically do anything about. This is an LPE that is fixed in the binaries that have already shipped. If I was playing cheerleader, this is exactly the case I&#x27;d use to argue that FreeBSD being a single unified system is a win and that its approach to handing security problems is very on top of things.

Its like rain on your wedding day - not actually ironic, just unfortunate.

A not-insignificant chunk of the userbase of the various BSDs is there because they were turned off of Linux after controversial things like Gnome 3, systemd being shoved down users&#x27; throats despite being a broken mess, wayland (though nobody was as arrogant about wayland as Poettering was about systemd), etc.All that to say, the BSD userbase as a sizeable subset that are there for countercultural reasons, rather than technical. These are the people who buy into, say, OpenBSD&#x27;s vaunted security reputation, or believe that &quot;linux bad because reasons&quot;, so you&#x27;re always going to get people in here bragging, because &quot;not using linux&quot; has become part of their identity.I run a mix of FreeBSD and Linux on my personal devices. The ground truth is that FreeBSD is yet another unix-like OS written in C, and thus not immune from the types of bugs that stem from that lineage. None of the BSD distros are materially more secure or better than a properly-configured and patched Linux.

Just yesterday, cperciva was bragging about the FreeBSD approach to security: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=48056853">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=48056853</a> You can certainly argue the response here was well-coordinated, but having an LPE in a nearly 50-year old core syscall like execve() isn&#x27;t ideal from a security perspective. (That is: security response isn&#x27;t the entire picture; culture and bug surface matter too.)

This is from April 28th, it was patched in 15.0R-p7.

Oof that&#x27;s a pretty big one, I didn&#x27;t realise but I had already updated anyway.

&quot;I just don&#x27;t write bugs&quot;Yeah.

<pre><code> memmove(args-&gt;begin_argv + extend, args-&gt;begin_argv + consume,
 args-&gt;endp - args-&gt;begin_argv + consume); &#x2F;&#x2F; ← bug
</code></pre>
C code like this is why we can&#x27;t have nice things. Arithmetic operation in the arguments of a dangerous function call with no explicit bounds check.

Anyone relying on a 30+ year old monolith kernel written in C to not have some exploitable LPEs lurking should stay in basket weaving and out of sysadmin.

Why can&#x27;t they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible&#x27;s playbooks for this exact scenario. You might also have it setup as a staggered rollout.

&gt; V. Solution&gt; Upgrade your vulnerable system to a supported FreeBSD stable or
release &#x2F; security branch (releng) dated after the correction date,
and reboot the system.Not everyone can just freebsd-update and reboot, so yes, &quot;Oh dear.&quot; is a good response to this.

I don&#x27;t think so? It&#x27;s a buffer overflow in the system call.

Does this vulnerability not rely on SUID binaries?

IV. WorkaroundAccept that everything is broken and terrible and yet somehow find a way to keep a sense of humor and smile about it.

I really am starting to think that the level of technical understanding on HN is so low that when readers see an exploit like this, they imagine basically the cult classic movie &quot;Hackers&quot; in their heads where some guy hacks into any machine of their choosing.

&gt; IV. Workaround&gt; No workaround is available.Oh dear.

&gt; I&#x27;m not sure how or what you&#x27;re counting.The recent two. FailCopy and DirtyFrag and FreeBSD with Execve.2 - Linux
1 - FreeBSD.Of course, all OS have had past-time exploits. Three now have made the news.

If you think Linux is on their first or second, I&#x27;m not sure how or what you&#x27;re counting.

Local privilege escalation is largely irrelevant on Windows because basically no one uses it in a multi-user system, and application sandboxing is effectively nonexistent.

You talk as if Windows is the only OS that has red teams attacking the system when clearly that isn’t even remotely true.

Plenty, Microsoft has security teams whose job is to attack Windows.Naturally they don&#x27;t do blog posts about what they find.

Linux is on their second and FreeBSD is on their first. How many is Windows on?

Local privilege escalation via execve()