0

I mean a scenario like this: There is some class (I call it victim) with a private data member and another class (named attacker) with some method, which, of course, normally does not have access to private members of other classes and does not even hold a reference to an instance of victim:

extern "C" {
#include <pigpiod_if2.h>
}

class victim {
private:
  static bool is_ready;
  static bool is_on;
public:
  static void init ()
    {
       is_ready = true;
       is_on    = true;
    }

  /* Some other public methods go here. */
}

class attacker {
private:
  static int last_read_pin;
public:
  static void run ()
  {
    while (true) {
      /* Some sensible code goes here. */
      last_read_pin = -1;
      time_sleep (0.01); // Using nanosleep () does not change behavior.
    }
  }
}

This is just a code snippet to illustrate the following question: Is it possible, not just in theory, but also practically, that attacker::run () can modify the values of the two private static vars of victim unintentionally, without addressing any public member of victim, maybe due to undefined behavior or even a compiler bug? Thank you.

UPDATE: After a hint from another user, I did rebuild the complete app using make clean and make. Also, I added the endless loop into my example. The change in is_ready occurs during the sixth run of the loop. Changing the sleep interval does not change behavior, though.

UPDATE #2: I ran my code through gdb with a watch on the is_ready variable, and I got an alert when last_read_pin was set to –1:

Hardware watchpoint 1: is_ready

Old value = true
New value = false
attacker::Run ()
last_read_pin       = -1;

UPDATE #3: Moving last_read_pin into the Run () method itself, thereby making it an internal variable, does not help either.

UPDATE #4: After simply commenting out the line of code, which makes so much trouble, the issue still persisten, apparently being caused by one line above, which reads like this:

keypad::last_levels [h] [k] = 0;

I had to comment out this line, too, to get rid of the problem with is_ready being changed.

Could the use of pigpiod cause this issue? I an earlier version, I was using pigpio directly and did not encounter this problem.

Compiled with gcc 4.9.2.

Neppomuk
  • 1,102
  • 1
  • 11
  • 24
  • 6
    Yes, anything is possible with undefined behavior. – melpomene Nov 16 '18 at 23:11
  • I am pretty sure you can abuse the language to do this *on purpose* (aka it's very obvious when you do it), I don't exactly recall how though. Maybe you are reading uninitialized memory (likely), corrupting the object memory (less likely) or encountering just another sort of weirdness in your real usecase - assuming your question is related to a real problem in a larger codebase. – asu Nov 16 '18 at 23:13
  • 5
    The private mechanism in C++ isn't a security system, and can be pretty trivially be got around. However, it's unlikely (though not impossible) that you can modify private member variables unintentionally. –  Nov 16 '18 at 23:19
  • @asu: Yes, my particular use case is about a much larger piece of code I can't post here for some reason. But: I do initialise my variables properly before running the run () method. – Neppomuk Nov 16 '18 at 23:27
  • 2
    Easy to do with a versioning problem. Old non-recompiled code uses a new class that is bigger. – Hans Passant Nov 17 '18 at 00:31
  • @Hans Passant: I issued `make clean` before compiling. Doesn't this suffice? – Neppomuk Nov 17 '18 at 17:41
  • Note that `private`/`public` is a red herring here. The point is that somebody writes where they are not supposed to. Eben a plain global variable's memory is only supposed to be accessed *through that variable* (and, if present, aliases), not through unrelated memory references (arrays, pointers). Such memory corruption is very easy to do in C/C++ and notoriously hard to find. – Peter - Reinstate Monica Nov 18 '18 at 15:40
  • OK, for myself, I am neither using the two variables in question in an array, nor am I using any pointers to them. – Neppomuk Nov 18 '18 at 16:34
  • @Neppomuk I guessed that much ;-). Some other pointer points there. With [gdb](https://stackoverflow.com/questions/58851/can-i-set-a-breakpoint-on-memory-access-in-gdb) or Visual C++ you can break when a particular address gets written to; that should give you a hint. (Oh, I see that you updated your question and did that already :-) ). – Peter - Reinstate Monica Nov 18 '18 at 16:40
  • 3
    If code like this leads to behaviour like you describe, you are most likely dealing with either a compiler bug or a hardware bug. Though one cannot exclude UB that occurs elsewhere weirdly interacting with this code. Another pissibility is gdb misidentifying the offending line. It is really hard to tell without seeing the whole picture. – n. m. could be an AI Nov 18 '18 at 16:45

1 Answers1

0

After floating around the code line in question, I found out that the blunder was lying in the line before, which reads as follows:

last_levels [h] [l] = 0;

Unfortunately, h can be < 0. In this case, some kinda exception (array index out of bounds) should be thrown, but unfortunately, it isn't (Does anybody know why?). The gdb gave me the wrong information of the overwrite of is_ready to happen in the following line (Is this maybe a bug?), and I believed this without any criticism. As if this wasn't enough, this error made no problems until I changed my code in a completely different place!

This blunder has cost me quite much time, but now, at last, I know what its cause was, and I corrected it successfully. Thank you anyway for your hints and comments!

Neppomuk
  • 1,102
  • 1
  • 11
  • 24