Announcement

Collapse
No announcement yet.

NVIDIA 295.40 Closes High-Risk Security Flaw

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NVIDIA 295.40 Closes High-Risk Security Flaw

    Phoronix: NVIDIA 295.40 Closes High-Risk Security Flaw

    NVIDIA's Linux team this morning announced the immediate release of the 295.40 Linux driver. There aren't many changes for this release compared to the recent 295.33 driver release, but it does address a high-risk security vulnerability...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    We all love blobs
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      Originally posted by darkbasic View Post
      We all love blobs
      Yes, we're still using a never-updated, initially released Debian 5 in our servers, since its packages are open source and therefore don't have security problems and thus don't need security updates.

      Dude, seriously :-P

      Comment


      • #4
        How long?

        I wonder how long this vulnerability have been known.
        It's just recently been officially announced as discovered, but may have been privately known for years.

        I want open source!

        Comment


        • #5
          Originally posted by uid313 View Post
          I wonder how long this vulnerability have been known.
          It's just recently been officially announced as discovered, but may have been privately known for years.

          I want open source!
          Like the root exploits in the Linux kernel that were there for years? Or the Debian SSL disaster? Give me a break.

          Comment


          • #6


            Seems to be an old vulnerability, fixed years ago by open source drivers

            Comment


            • #7
              Look at all the goodies the Windows side is getting in the next driver. :|

              Comment


              • #8
                Originally posted by RealNC View Post
                Like the root exploits in the Linux kernel that were there for years? Or the Debian SSL disaster? Give me a break.
                The case is if those exploits were known. If they weren't then what's your point? The only thing that really matters is a time needed for fixing an exploit and Linux is probably the fastest in this. However, according to Phoronix article it seems nVidia does a good job as well.

                Comment


                • #9
                  Originally posted by RealNC View Post
                  Yes, we're still using a never-updated, initially released Debian 5 in our servers, since its packages are open source and therefore don't have security problems and thus don't need security updates.
                  Classy. Actually, no distribution makes fire-and-forget security (dist-upgrade in cron) more easy than Debian.

                  Regarding the point of uid313's posting, if there is a security bug in Debian or the Linux kernel, everybody can see how long the vulnerability existed, how it came to be and who was responsible. Also it is sometimes possible to tell whether it was neglect, ignorance or malicious intent which caused the bug.

                  Comment


                  • #10
                    Originally posted by chithanh View Post
                    Classy. Actually, no distribution makes fire-and-forget security (dist-upgrade in cron) more easy than Debian.
                    If that's your idea of server administration, then I must say you need to rethink. dist-upgrade needs oversight and a check on what processes still use the old deleted files.

                    Regarding the point of uid313's posting, if there is a security bug in Debian or the Linux kernel, everybody can see how long the vulnerability existed, how it came to be and who was responsible. Also it is sometimes possible to tell whether it was neglect, ignorance or malicious intent which caused the bug.
                    Placing blame is actually stronger in corporations than in open source contributors. If I contribute a piece of code and two years later it turns out there's a critical flaw in, well yeah, cry me a river. Mistakes happen. If I'm an employee and make the same mistake, I would care more about making mistakes and not pissing off the QA guys.

                    Comment

                    Working...
                    X