3 ms·

> Proper tooling with C can prevent memory issues So far this year, the Linux kernel has 849 overflow and memory corruption CVEs: https://www.cvedetails.com/pr

> Proper tooling with C can prevent memory issues So far this year, the Linux kernel has 849 overflow and memory corruption CVEs: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... What is your advice to the Linux kernel developers who, by your logic, are not using proper tooling? I’m not willing to tell them they’re doing it wrong because they’re experts in a very technically challenging field I don’t know much about. What is it you think they’re doing wrong, given your experience?

shepherdjerred 2y ago
My favorite illustration of this is Xe’s blog: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
- kstrauser 2y ago
  For sure. That was adapted from https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1819576527/ https://theonion.com/no-way-to-prevent-this-says-only-nation... but still rings true. If only there were someone to avoid these huge arenas of error-prone, demonstrably impossible to write correctly conditions! Rust, Zig, D, OCaml, Erlang, Haskell, programmers look at each other disappointedly
  - pjmlp 2y ago
    It is even worse than that, paraphrasing you, ESPOL, NEWP, PL/I, PL/S, PL.8, Mesa, Modula-2, Ada, Object Pascal, programmers look at each other disappointedly Even taking into consideration the systems programming languages until the 1980's, the list isn't exhaustive.
    - kstrauser 2y ago
      Oh sure! C/C++ are the only current major languages that spring to mind that make it so easy to shoot your foot clean off. Assembler, I guess, except it’s not nearly so widely used and everyone knows what they’re getting into with it.
favorited 2y ago
> the Linux kernel has 849 overflow and memory corruption CVEs 4 years ago, they had 40 memory-corruption-related CVEs. Their actual vulnerability count hasn't increased by 2122% over 4 years – rather, they've become a CVE numbering authority and have started self-assigning CVEs even when there is no evidence of a vulnerability: > Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assigns CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team. <https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter-c7c8@gregkh/ https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter...> Having a huge number of self-issued CVEs is a policy decision on the part of the Kernel maintainers.

shepherdjerred 2y ago

My favorite illustration of this is Xe’s blog: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...

kstrauser 2y ago
For sure. That was adapted from https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1819576527/ https://theonion.com/no-way-to-prevent-this-says-only-nation... but still rings true. If only there were someone to avoid these huge arenas of error-prone, demonstrably impossible to write correctly conditions! Rust, Zig, D, OCaml, Erlang, Haskell, programmers look at each other disappointedly
- pjmlp 2y ago
  It is even worse than that, paraphrasing you, ESPOL, NEWP, PL/I, PL/S, PL.8, Mesa, Modula-2, Ada, Object Pascal, programmers look at each other disappointedly Even taking into consideration the systems programming languages until the 1980's, the list isn't exhaustive.
  - kstrauser 2y ago
    Oh sure! C/C++ are the only current major languages that spring to mind that make it so easy to shoot your foot clean off. Assembler, I guess, except it’s not nearly so widely used and everyone knows what they’re getting into with it.

favorited 2y ago

> the Linux kernel has 849 overflow and memory corruption CVEs 4 years ago, they had 40 memory-corruption-related CVEs. Their actual vulnerability count hasn't increased by 2122% over 4 years – rather, they've become a CVE numbering authority and have started self-assigning CVEs even when there is no evidence of a vulnerability: > Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assigns CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team. <https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter-c7c8@gregkh/ https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter...> Having a huge number of self-issued CVEs is a policy decision on the part of the Kernel maintainers.