3 ms·

I agree the wording is a bit alarmist, but a closer example to what they are saying is: bool silly_mistake = false; //... lots of lines of code free(

by QuiEgo 6mo ago

I agree the wording is a bit alarmist, but a closer example to what they are saying is: bool silly_mistake = false; //... lots of lines of code free(x); //... lots of lines of code if (silly_mistake) { // silly_mistake shown to be false at this point in the program in all testing, so far free(x); } A bug like above would still be something that would be patched, even if a way to exploit it has not yet been found, so I think it's fair to call out (perhaps with less sensationalism). FWIW there's a whole boutique industry around finding these. People have built whole careers around farming bug bounties for bugs like this. I think they will be among the first set of software engineers really in trouble from AI.

userbinator 6mo ago
That is something a good static analyser or even optimising compiler can find ("opaque predicate detection") without the need for AI, and belongs in the category of "warning" and nowhere near "exploitable". In fact a compiler might've actually removed the unreachable code completely.
- QuiEgo 6mo ago
  Well yeah, it’s a toy example to illustrate a point in an HN discussion :). Imagine “silly mistake” is a parameter, and rename it “error_code” (pass by reference), put a label named “cleanup” right before the if statement, and throw in a ton of “goto cleanup” statements to the point the control flow of the function is hard to follow if you want it to model real code ever so slightly more. It will be interesting to see the bugs it’s actually finding. It sounds like they will fall into the lower CVE scores - real problems but not critical.
  - userbinator 6mo ago
    That's what I'm saying; a static analyser will be able to determine whether the code and/or state is reachable without any AI, and it will be completely deterministic in its output.
    - array_key_first 6mo ago
      You cannot tell if code is actually reachable if it depends on runtime input. Those really evil bugs are the ones that exist in code paths that only trigger 0.001% of the time. Often, the code path is not triggerable at all with regular input. But with malicious input, it is, so you can only find it through fuzzing or human analysis.
      - userbinator 6mo ago
        You cannot tell if code is actually reachable if it depends on runtime input. That is precisely what a static analyser can determine. E.g. if you are reading a 4-byte length from a file, and using that to allocate memory which involves adding that length to some other constant, it will assume (unless told otherwise) that the length can be all 4G values and complain about the range of values which will overflow.
    - ascorbic 6mo ago
      Why hasn't it then? The Linux kernel must be asking the most heavily-audited pieces of software in existence, and yet these bugs were still there.
      - userbinator 6mo ago
        People find and report bugs in the kernel using static analysers all the time.

by QuiEgo 6mo ago

userbinator 6mo ago

That is something a good static analyser or even optimising compiler can find ("opaque predicate detection") without the need for AI, and belongs in the category of "warning" and nowhere near "exploitable". In fact a compiler might've actually removed the unreachable code completely.

QuiEgo 6mo ago
Well yeah, it’s a toy example to illustrate a point in an HN discussion :). Imagine “silly mistake” is a parameter, and rename it “error_code” (pass by reference), put a label named “cleanup” right before the if statement, and throw in a ton of “goto cleanup” statements to the point the control flow of the function is hard to follow if you want it to model real code ever so slightly more. It will be interesting to see the bugs it’s actually finding. It sounds like they will fall into the lower CVE scores - real problems but not critical.
- userbinator 6mo ago
  That's what I'm saying; a static analyser will be able to determine whether the code and/or state is reachable without any AI, and it will be completely deterministic in its output.
  - array_key_first 6mo ago
    You cannot tell if code is actually reachable if it depends on runtime input. Those really evil bugs are the ones that exist in code paths that only trigger 0.001% of the time. Often, the code path is not triggerable at all with regular input. But with malicious input, it is, so you can only find it through fuzzing or human analysis.
    - userbinator 6mo ago
      You cannot tell if code is actually reachable if it depends on runtime input. That is precisely what a static analyser can determine. E.g. if you are reading a 4-byte length from a file, and using that to allocate memory which involves adding that length to some other constant, it will assume (unless told otherwise) that the length can be all 4G values and complain about the range of values which will overflow.
  - ascorbic 6mo ago
    Why hasn't it then? The Linux kernel must be asking the most heavily-audited pieces of software in existence, and yet these bugs were still there.
    - userbinator 6mo ago
      People find and report bugs in the kernel using static analysers all the time.