Hi Theo!

I”ve been following your work for a while and if I’m honest I have been holding 
off on submitting my bug reports because I was convinced you were going to tear 
me a new one and I couldn’t possibly have found anything in OpenBSD.

I found four problems and it’s clear the out of memory issue is not a bug.  

The other three reports are, stripped of all the gobbley gook:

1.  ccr.c:1283 — parse_aspa_providers() checks p_num <= 0 but not p_num >= 
MAX_ASPA_PROVIDERS. The equivalent function in aspa.c (line 66) has the 
upper-bound check so I flagged this as an inconsistency during code review.

2. http.c:1631 — http_redirect() is called when http_isredirect() returns true 
(status code only), but conn->redir_uri is only set when a Location: header is 
parsed. A 301 with no Location header passes NULL through http_info() to 
strnvis(). Fix: check  conn->redir_uri != NULL before calling http_redirect().

3.  as.c:75-7: as_check_overlap() uses `ases->range.min` and `ases->range.max` 
instead of `as->range.min` and `as->range.max`.  Compares ases[0] against 
ases[i] instead of the incoming entry against ases[i]. Every other branch in 
the function uses `as->`.
   I see no reason why we’d check ases->range.min instead of as->range.min as 
everywhere else (which is why I see this as a bug).

Feel free to be brutal with your feedback.  Honestly I’m going to get a kick 
out of it (used to read some of your comments on the mailing list in college 
before I stopped using OpenBSD).

These reports were found with a tool I’ve built for linting that goes through 
entire codebases looking for inconsistencies that are potential issues, which I 
get in a report.  Happy to tell you about it if you’re interested, but these 
were reviewed by me, for what that’s worth.  Which maybe is not much at 
midnight...  

Thank you for looking at my reports,

Dan


> On Apr 8, 2026, at 11:44 PM, Theo de Raadt <[email protected]> wrote:
> 
>  On a memory-constrained system, this may trigger the OOM killer and
>  affect other processes.
> 
> So you are saying that if one process allocates too much memory
> it can kill other processes?
> 
> Do you mean entirely unrelated processes running as a totally different
> uid for completly other purposes?
> 
> That sounds like a pretty serious issue in such operating systems.
> 
> In fact that issue sounds far more serious than what you are sending here.
> 
> Is that news?
> 
> Do you intend to cause some action against that problem?
> 
> Or, maybe are you just using AI?

Reply via email to