Re: fork(), I just meant to be thorough in explaining the environment is copied, not shared by processes. Setenv() only affects the process from which it’s called.
The array size bit in the article: The value 0x220 looks suspiciously close to the size of the old environment in 64-bit words (0x220 / 8 = 68), and this value was written over the terminating NULL of the environment block…
HTH!
I clarified why I mentioned fork().
I tried to explain the difference between registers and variables.
I’m not trying to show off or bring anyone down… I just like to help people. I’m old (my first Linux kernel commit was in 2004). And I could be wrong — please LMK if I made a factual error (I’d appreciate it, honestly).
All good?
The article specifically mentions that the authors consulted the disassembly to see what was in x20. I know it is a general purpose register. They know it is a general purpose register. This knowledge is completely irrelevant: they read the code, they matched it against the actual source, they can confirm that at the time of crash x20 contains what they said it contains. The compiler optimizations have already run. They can't change anything anymore. That you mentioned this shows that you do not follow the actual order of events here.
envp, similarly, is in the process of being operated on in the crashing code. The authors grabbed its size from some random context at the time of the crash. The fact that it is not actually stored in the array itself is completely irrelevant to the fact that its numeric value was present in the crash dump. Obviously, some code that operated on it had computed the value and stashed it, which is a completely natural and expected thing for this code to do.
Finally, nobody cares about setenv across processes. The article didn't talk about this. It's completely irrelevant to mention this, and in fact there is another comment further down (which you may not have read, I'm ok with that) that also has the same confusion and it belies a poor grasp of what the actual problem is.
You can see that I am forced to do significantly more work than you to respond to what specifically is the problem here. It looks like you are pattern matching on specific words and then regurgitating your knowledge on it, whether it is relevant or not. When it's not, it's essentially just spam; when it is you fail to actually take into account the content that is actually being discussed. When I'm talking about how I almost got run over by a driver on their phone you are not welcome to step in and start talking about how a lot of hit-and-runs involve drunk drivers. I wasn't talking about a hit-and-run, and I just told you the person was on their phone. Somehow you completely missed that and kept talking about what you wanted to mention, like if you gave the gist of the conversation to someone else and asked them for their response on it and then pasted that here without checking to see if it was relevant or not. Don't do that.
It does not help, because you do not appear to have understood the article (or even read it all that closely).
Some of these bullet points feel a lot like the kind of junk output one sees from the various (popular, but flawed) AI summary tools...
I could be wrong though —- could you be specific? I don’t want to misinform anyone…
3. There's nothing wrong with the level of abstraction here. If you have a crash that occurs on ARM but not on amd64, the differences in how those architectures operate is a very reasonable initial assumption.
4. The value in x20 is the same value in the local variable in question. Even though there may not be a general one-to-one mapping between variables and registers, at this particular instant in time that variable does correspond to this register.
5 is irrelevant, as the article isn't discussing forking. It's discussing the (somewhat questionable) practice of a program using getenv/setenv as mutable state.
For 6, the article doesn't say that env stores its own array length. It says that setenv called something like free() on the old env array, and free() overwrote env with the length of the memory allocation (which is a quite reasonable way for malloc to do book keeping).
1. If a process crashes and dumps, be sure to look at the system log of the cause (e.g. SIGSEGV, OOM, invalid instruction, etc.)
2. Be certain you’re looking at the right core dumps — I believe UID 1000 just means posix UserID (which is unrelated to a PID), though I don’t use containers.
3. Stay focused on the right level of abstraction — memory model details are great to know, but irrelevant here.
4. Variables do not correlate 1:1 with registers, except in C calling conventions. The assumption about x20 and a local variable is incorrect, unfortunately.
5. getenv() and setenv() do not work as implied in the post. When a process starts via execve(), the OS/libc constructs a new snapshot of the environment, and cannot be modified by an ancestral process. It’s a snapshot in time, unless updated by the process itself. When a process fork()s, the child gets a new copy of the parent’s environment — updates do not propagate.
getenv() is thread safe and reentrant. You don’t use an environment to pass shared data — setenv() is generally used when constructing the environment for a child process before a fork(). See man environment.
6. FWIW, ‘char** env’ is a null-terminated array of pointers, so dumping memory from *env (or env[0]) is only valid until you hit the first NULL. The size of the array is not stored in the array.
I hope this helps! And apologies if this is redundant — I read so many comments; mostly variations of “the problem with getenv is x”, but gave up before reading all of the (currently) 168 comments.