Seemingly as an accident, overnight several new Linux kernel vulnerability reports were posted to the public Linux kernel mailing list rather than the private security mailing list. The vulnerabilities have yet to be patched on mainline but at least in some cases there are patches undergoing testing or queued in "-next" branches. The CVSS scores are as high as 9.0.

Trend Micro's Zero Day Initiative sent out a number of vulnerability reports to the public Linux kernel mailing list (LKML) rather than the typical private security mailing list. This seemingly was a mistake with Linux's second-in-command Greg Kroah-Hartman responding to each report asking about their submission to the public mailing list.

Among these newly-disclosed vulnerabilities include:

ZDI-CAN-33549 as a CVSS 9.0 scored vulnerability for SMB Direct remote code execution vulnerability due to integer underflow. For this one there is a patch in a Git branch of code intended for Linux v7.5 but now presumably will be expedited for getting to mainline.

ZDI-CAN-33774 as a KSMBD race condition that can lead to remote code execution. Another CVSS 9.0 rated vulnerability.

ZDI-CAN-33367 is a vulneravbility for skbuff skb_zerocopy in the network code that can lead to local privilege escalation. For this one Linux kernel developers received a security report from another source last week over the same issue and a patch is expected to be posted soon.

ZDI-CAN-34068 as a VMWGFX VMware graphics driver bug with an out-of-bounds write leading to local privilege escalation.

ZDI-CAN-34076 an uninitialized resource in the NVMET code leading to information disclosure.

ZDI-CAN-32005 was also posted to the mailing list a day prior for a search-domain TCP query stack buffer overflow leading to local privilege escalation.

The bug and security reports keep on coming in the AI fueled world.

all 4 comments

sorted by: hot top controversial new old
[–] 4 points 2 weeks ago (2 children)

Did... did an agent post them?

  • source
  • hideshow 2 child comments
  • [–] 0 points 2 weeks ago

    Slightly offtopic, but....

    This should be pretty trival to show if all these AI assisted researchers are finding human coded bugs or recent-ish bugs contributed by AI....

    surely that would be solid proof that LLMs are somewhat useful

  • source
  • 22 comments in c/linux@programming.dev view that post
    [–] 38 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

    I only program in Excel conditional statements and I never get these vulnerabilities.

    Excel is therefore proven the most secure coding language, and like a Swiss pocket knife it doubles as an industrial grade database.

    (pats hood) Listen to that xls(x) purrr..

    Oh no sorry I can't show you right now, I had to open my spreadsheet so it'll be a few hours til I can start work.

  • source
  • hideshow 3 child comments
  • [–] 19 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

    https://youtube.com/watch?v=IrVA1BBHFHw&ra=m

    Oh, sorry, I couldn’t hear you over this BITCHING ROLLER COASTER BUILT IN EXCEL

    I got sent an excel file with a full volumetric heat diffusion simulation once, and it was most impressive thing until I heard about this roller coaster

  • source
  • parent
  • hideshow 2 child comments
  • [–] 10 points 2 weeks ago

    Can I at least get some sleep please? Jeez... How many more fires I will have to put out this week?

  • source
  • [–] 8 points 2 weeks ago

    At least it sounds like the 9.0 ones only affect systems that are running SMB Direct, which sounds like a pretty niche setup

  • source
  • [–] 18 points 2 weeks ago (15 children)

    SMB Direct remote code execution vulnerability due to integer underflow.

    It's a day ending in 'y' and we've found another RCE that wouldn't exist in a modern language designed to catch things like integer under/overflow.

  • source
  • hideshow 15 child comments
  • [–] 24 points 2 weeks ago (11 children)

    Yes, we get it, you like rust.

  • source
  • parent
  • hideshow 11 child comments
  • [–] 29 points 2 weeks ago* (last edited 2 weeks ago) (10 children)

    I mean yes, I do, given safe Rust inherently fixes seemingly every exploit listed in this article:

    • RCE from integer overflow (not possible by default in Rust, CVSS 9.0)
    • RCE from a race condition (not possible in safe Rust, CVSS 9.0)
    • An exploit of a buffer copy
    • An out-of-bounds write leading to local privilege escalation
    • Using an uninitialized resource
    • TCP query stack buffer overflow leading to local privilege escalation

    I feel like it's the 1960s and I'm being told "we get it, you like seatbelts".


    Edit: Sorry, re: the first one. I was misremembering based on a mix of a few things (see below). It does this in debug mode (which in itself is good to have), and it won't compile if it can detect an overflow statically, but it's not checking over/underflow at runtime by default. It can do this if you want it to, but that's an inherent speed penalty from C. I was thinking of Swift, which does automatically detect integer under/overflow at runtime unless you explicitly tell it not to on a per-operator basis.

    In the spirit of not making you "trust me bro" since I was so wrong about the integer under/overflow one, here's Rust's overview of how safe Rust guarantees against data races.

  • source
  • parent
  • hideshow 10 child comments
  • [–] 7 points 2 weeks ago (1 child)

    RCE from integer overflow (not possible by default in Rust

    It is possible. Rust will check for overflow and panic in debug builds, but will silently wrap integers in release builds.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 weeks ago*

    Yeah, you're right. I was thinking of a combination of Rust's debug mode, the fact it won't compile if it detects a static under/overflow, and Swift's default producing a runtime error on integer under/overflow. Corrected; I apologize.

  • source
  • parent
  • [+] -11 points 2 weeks ago (6 children)

    Yeah because the way you said it is extremely dick-ish and sounds like someone trying to push their preferred language onto others.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 29 points 2 weeks ago* (last edited 2 weeks ago) (5 children)

    > "sounds like someone trying to push their preferred language onto others."

    > didn't even name Rust in the first comment

    I literally only talked about Rust when someone else mentioned it, because I'm not specifically talking about Rust.

    Whereas yes, Rust is relevant to the Linux kernel for obvious reasons (matching C's speed and being easily interoperable with it), I said "a modern language" because I'm talking generally about the use of old, unsafe languages and major exploits surrounding problems that modern languages fix cropping up every 5 seconds.

    I'm not going to police my own tone about what are clearly negligent engineering practices. SWE should be treated with the same level of scrutiny as other engineering fields when its poor, outdated practices are constantly causing accelerating worldwide damage.

  • source
  • parent
  • hideshow 5 child comments
  • [+] -13 points 2 weeks ago (4 children)

    Everyone is sick of this low effort advocacy

  • source
  • parent
  • hideshow 4 child comments
  • [–] 9 points 2 weeks ago (1 child)

    Idk, I find it pretty informative.

  • source
  • parent
  • hideshow 1 child comment
  • [–] -3 points 2 weeks ago

    Cool, that's fine. I think it was clear I didn't mean literally everyone. At least for me the boosterism has been pretty relentless for many years, taking over from the Python dogmatism before that.

    The languages are cool and have many nice aspects, the volunteer advertising is tiresome though.

  • source
  • parent
  • [+] -7 points 2 weeks ago (2 children)

    Start stroking your keys on your keyboard in said language and fix the RCE yourself instead of typing stuff here that contributes to nothing.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 50 points 2 weeks ago* (last edited 2 weeks ago) (1 child)

    "Quit complaining about fixable systemic issues unless you're able to personally go fix them yourself. Bridges collapsing due to negligent engineering practices? Go survey and fix them yourself. I am very smart."

  • source
  • parent
  • hideshow 1 child comment
  • 16 comments in c/linux@lemmy.ml view that post
    [–] 69 points 2 weeks ago (2 children)
  • [–] 4 points 2 weeks ago

    Honesty is the best policy??

  • source
  • [–] 21 points 2 weeks ago* (last edited 2 weeks ago) (11 children)

    This seemingly was a mistake with Linux’s second-in-command Greg Kroah-Hartman responding to each report asking about their submission to the public mailing list.

    I hope that was not AI automation, with him being a lover and a loud public advocate of it.

    EDIT: we've misread the text. It wasn't a mistake by Greg, but merely that he was the one to reply. Nobody directed Trend Micro to the public mailing list, they did it by themselves (as far as we know).

  • source
  • hideshow 11 child comments
  • [–] 23 points 2 weeks ago (1 child)

    What does it have to with Kroah-Hartmans stance on AI when it wasn't him that made the mistake?

    This here was the mistake that Kroah-Hartman was questioning:

    Trend Micro's Zero Day Initiative sent out a number of vulnerability reports to the public Linux kernel mailing list (LKML) rather than the typical private security mailing list.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 weeks ago

    What does it have to with Kroah-Hartmans stance on AI when it wasn’t him that made the mistake?

    Because any mistakes he does is of cause due to some AI glitch, that proves that he is wrong about saying anything positive about AI, and it could never be something else. Well, beside that it wasn't him that posted to the wrong mailing list.

  • source
  • parent
  • [–] 16 points 2 weeks ago* (2 children)

    As other replies to you have touched on, I believe you've misread/misunderstood that, although I understand why. It definitely could've been worded more clearly.

    What it means is more along the lines of:

    This seemingly was a mistake. Linux’s second-in-command Greg Kroah-Hartman responded to each report asking about their submission to the public mailing list.

    He's not the one that submitted them. He's the one that replied to them asking "wtf!?"

  • source
  • parent
  • hideshow 2 child comments
  • [–] 15 points 2 weeks ago* (2 children)

    with him being a lover and a loud public advocate of it.

    I googled the guy's name and as expected, I found him suggesting ai is good for finding bugs now, unlike in the past. No quotes of him praising its use let alone across the board.

    I am generally against AI but what exactly is the point of opposing it to the point of denying it has any use whatsoever, exaggerating anything anyone says remotely in favor of it, or in this case making up harm that AI hypothetically may have caused? Doing things like that is just destroying the credibility of opposing AI, and I see this kind of approach to it constantly on here.

    No, Linux is not "vibecoded" now. No, Torvalds is not an AI simp now. Yes, there are some uses of AI that are probably worth the downsides (which anyone can see and should admit to). Binary thinking is not productive.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 weeks ago (1 child)

    I just want to point out that you wrote your comment after I've already edited mine, where I've clarified that I misread the text in the post.

    I've simply misread. Please don't add too many constructs about AI on top. It was easy to misread IMO too, others have done as well.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 weeks ago

    So, I get that, I was commenting on the exaggeration of this guy's ai stance and the assumption that ai had something to do with this mistake. Additionally, I was commenting on how common these types of things are on Lemmy. You owned up to your immediate mistake here and that's good, but my other points still stand.

  • source
  • parent