back to article After reportedly dragging its feet, BlackBerry admits, yes, QNX in cars, equipment suffers from BadAlloc bug

BlackBerry this week issued a critical security advisory for past versions of its QNX Real Time Operating System (RTOS), used in more than 175m cars, medical equipment, and industrial systems. BlackBerry QNX Software Development Platform (SDP) version 6.5.0SP1 and earlier, QNX OS for Medical 1.1 and earlier, and QNX OS for …

  1. nintendoeats Bronze badge

    If I understand correctly, the memory safety in Rust comes primarily from static analysis mandated by the standard (outside of explicitly specified "unsafe blocks"). So if there is a memory allocation bug in a runtime library, no amount of safety built into the language is going to help right? After all, in the end the compiled code is still just pointers and offsets (with all the usual lack of safety guarantees).

    1. diodesign (Written by Reg staff) Silver badge

      Rust

      I just knew if I left the reference to Rust in, we'd get dinged on it. I've just decided to take that sentence out rather than argue at length over it. We wrote at the end, regarding the BadAlloc hole in QNX:

      "Such bugs explain why the Rust programming language, capable of memory-safety and type-safety, has become popular in recent years at companies like AWS, Google, and Microsoft."

      Would Rust have prevented this specific bug? Maybe, depending on how it was used. You could use Rust's checked math operations that catch overflows, if you remember to use them; debug mode has them on by default. If the overflow is in a separate C lib, you're out of luck.

      Is it a good idea to use Rust to avoid similar memory bugs - like what Google, AWS, and others are doing - yes. We mentioned Rust in a general sense because at least some devs look at bugs like BadAlloc, think, 'there but for the grace of God, go I' and opt to use Rust to minimize similar, related flaws to improve the quality of their shipped code.

      C.

      1. runt row raggy

        Re: Rust

        rust isn't a panacea.

        in my recent professional experience, the code that has has the most catastrophic bugs leaving core dumps and deleted databases has been rust. sure, this is an anecdote but my point is pointing at one small class of bugs that rust does solve and blithely generalizing chanting web scale, er, i mean rust at any class of bugs you can think of isn't correct.

        i think rust brings some great safety that other languages haven't brought before, but saying it's a (memory) "safe" language and implying that all rust is safe to run in the general sense is linguistic substitution.

      2. Kevin McMurtrie Silver badge

        Re: Rust

        I have doubts about this code being at a high enough level of abstraction for Rust to understand the bug. Memory management is just a pile of math until those numbers are finally cast into meaningful data structure references.

      3. MacroRodent Silver badge

        Re: Rust

        > You could use Rust's checked math [...]

        A low-level allocation library will almost certainly not enable runtime checks, in the name of efficiency. A "safe" language is probably safe only if its implementation has absolutely no way to turn the checks off.

  2. -tim
    Facepalm

    This bug is everywhere else too

    QNX appear to use the same calloc as many GNU projects and the same bug has been in MS products since they learned to love C. calloc has always been odd when called with out small sizes that are nice powers of two since the function might just try to guess how things are aligned. A calloc(10,5) might assume that 10 items need to be 8 byte aligned (like large floating point numbers on a number of older architectures) and allocate 80 bytes compared to the 50 that many programmers would expect. It is another C function that was useful in its day and now shouldn't be used. Does calloc(3689348815, 5000000000) return a null on your system (assuming you can malloc 1.3g)?

    1. MacroRodent Silver badge

      Re: This bug is everywhere else too

      A calloc that tries to make assumptions about alignment based on the inputs is just an invalid implementation. The C standard says "The calloc function allocates space for an array of nmemb objects, each of whose size is size. The space is initialized to all bits zero." It cannot assume the size is not really size, but something larger. Typically the second parameter is sizeof(something), and if "something" has alignment requirements in an array, sizeof already takes care of rounding up.

      All implementations I have seen just multiply the numbers together and call malloc with them (or call the same internal function malloc calls). The only gotcha is if the implementer does not realize the multiplication can overflow and wrap to something less than either size parameter. Sadly, that is how many callocs are...

  3. Captain Scarlet
    Unhappy

    2012 and earlier

    So they are never getting updated by the manufacturer, never was able to get Ford to check for firmware updates for my 13 plates Fiesta's system which likes to throw wobblies when the car is off and lose active settings even know USA could download firmware to a usb stick themselves.

    1. Captain Scarlet

      Re: 2012 and earlier

      Assuming the downvoter wanted to point out its an MS system which is true, I believe Ford implemented Blackberries OS after my model Fiesta was revised.

  4. sitta_europea Silver badge

    I've worked with instrumentation, computers, computer-controlled machinery and networks - designing, building, using, maintaining, protecting and (lately) defending the bloomin' things - for more than forty years in all sorts of settings.

    I know what they're good, and what (and where) they're not so good. I know what the risks are.

    In my car (and worse - on my motorcycles, three of which can comfortably exceed twice the highest speed limit on our public roads, and one of which can on a good day exceed three times that limit) I am going to be in situations which, if something goes seriously wrong with the vehicle, will be at least very seriously embarrassing and, in the case of the faster motorcycles, quite likely fatal to the driver.

    The car and the motorcycles are all around twenty years old.

    I can live with the electronics, but I really do NOT want computers in them, thank you very much, and that is *why* they're all around twenty years old.

    1. sev.monster Bronze badge

      Even 20 years ago, manufacturers were already using computers for fuel injection, timing, dual-clutch transmissions, lights, locks, and more. In fact ECMs were standard in most higher-end cars by the 70's and most cars in general by the 80's, at least here in the States. Of course, things like power locks and windows would not become more common until later since they were a "luxury feature" for a time.

      Might want to check your manuals and confirm what ECUs your automobes actually contain, I'm sure you'd be surprised.

      1. Sam Liddicott

        I bet they aren't using calloc

        1. sev.monster Bronze badge

          Many of them likely didn't have microprocessors, or at least didn't utilize a complex instruction set, so that's likely :)

          My point was just that OP should have quantified what kind of vehicle-bound computer he wasn't fond of. I assume I would get an agreement with the statement that infotainment, wireless connectivity, and other such gubbins have no place in a car, but that critical low-level stuff like timing control modules (and similar modules that handle and are only able to handle one specific task) are good.

  5. sitta_europea Silver badge

    Been writing stuff in C since the late 1970s.

    Never used calloc().

    1. Paul Crawford Silver badge

      I normally use calloc() due to the zeroing of memory, so any use-before-initialisation has a repeatable fail.

      However, to me it seems the issue really comes down to a lack of input sanitization if some external entity can fool you application in to a integer-fault situation.

      If you did malloc(size*num) I guess you have the same problem unless 64-bit and you are happy for the system to grind to a halt as it allocates a brazillion bytes of memory and the swap kicks in...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021