NULL pointer deref in do_blockdev_direct_IO() #13
Comments
Closed
|
I believe it would be necessary to post the Call Trace here in this location. I'll try now. I'd be very much interested to know what that could be... Any information that would be needed I'll try to do my best to provide. This happened similarly a few times. I'll try and see if I can explain more, and as systematically as I can, at the address given in the first post grsec-unoff RAP related Call Traces |
|
@HacKurx, I'm afraid there are still issues with the patch for 4.9.62. There's much more at: |
|
Here is what changed in 4.9.62: |
theLOICofFRANCE
added a commit
to theLOICofFRANCE/public-sharing
that referenced
this issue
Nov 19, 2017
Test for 4.9.62 and 4.9.63. Because a problem has been reported by miroR: minipli/linux-unofficial_grsec#13 (comment)
Can you test that. Thanks. |
I'll first try and check if it too late to test that. (I was first overwhelmed with system not working, than I was busy, I'm sorry.) And if it's too late (as it looks to be), I guess it is better to test: |
|
Ah, I see (slow at reading the logs and the sources a little). |
|
I'm running 4.9.63 with your patch, and the partial-reverse-commit: No telling yet, because: But so far, so good. No issues in this short yet. |
Nope! The system froze dead again... |
|
Here's a fresh one, and even though it's 4.9.61 HacKurx-patch kernel, I believe I owe it somehow (will hopefully be able to explain the circumstancial indications to that) to the 4.9.63 same-author patch kernel. Also, this time it may be related to RAP: |
minipli
changed the title
|
This is not RAP related, as far as I can see. The kernel Oopses in Can you please post your kernel config and the filesystem type and mount options you're using for the following paths?: |
|
First, I can't say how happy I am you'r back, @minipli !
Hmmh... I'm sure you're right... (vague is my understanding)
But I'm not sure what you mean by mount options for these: and also: My /usr is on the already above pasted: Kernel config coming next. |
You need the whole config: /boot/config-4.9.61-unofficial+grsec171114-20, pls. say, but I'll encrypt it to your PGP-key and post it on my site. |
|
After HacKurx posted #20 (comment) (and see my ramblings afterwards, pick out what's relevant from it), I went and compiled vanilla 4.14.4. |
|
I had compiled the 4.14.4171209-12 # 1 from the above Call Trace under RBAC deployed, but it was with minor fault because of some perms in rules missing, because it complained about LD_PRELOAD and shared memory segment (or so, can't look up the log right now, allow correction later). because that was the last thing I saw before the freeze. By the way, with 4.9.67 grsec-unoff patched, still no more crashes... Load-running tasks on it as I write... |
|
As far as tor that I suspected might be involved because of the OpenSSL header-mismatch as in #20 (comment) Again, with 4.9.67 grsec-unoff patched, still no more crashes. |
|
I'm browsing with the "all-modules-for-all-systems" kernel, which I offer for the brave at: https://croatiafidelis.hr/gnu/deb/linux-image-4.9.67-grsecunoff-171209-20/ |
|
I'm sorry, I have to close this one. You're mixing up multiple bugs here which makes this a mess to follow. The initial bug -- the NULL pointer deref in do_blockdev_direct_IO() -- is interesting. The kernel crashes while trying to execute some binary -- presumably some filter program executed by tshark. You even managed to reproduce the bug in comment #10. Again the very same NULL deref, triggered by tshark. The next bug -- a general protection fault in vma_wants_writenotify() -- is interesting too. It's interesting because the instruction that traps tries to dereference the memory location pointed by the RAX register. Looking at RAX, it's 0xff8803194de000ff. That's indeed a non-canonical address, as its uppermost 16 bits are neither all 0 or all 1. That explains the #GP. However, if you rotate that value by 8 bit to the right, it'll look like a valid kernel address... Confusing, I know, but just some thoughts about the bug. A few comments later you hit a bug with a NULL pointer deref related to a spin lock within the UNIX domain sockets code. That was on vanilla Linux v4.14, though. So nothing to look at (yet). After that another invalid pointer deref is posted. This time without frame pointers so the backtrace is unreliable. However, it's a code pointer that traps, e.g. the kernel branched off the control flow to an invalid address. Very odd -- and bad! But, again, this was on vanilla Linux, so nothing to worry about (yet). Also, the i2c error message is hardly related to the panic. It happens almost 5 minutes before the panic and is just some diagnostic message that some i2c command has failed. Nothing to worry about. That mentioning of tor later on makes no sense to me whatsoever.... Anyways, that's at least four different (kernel) bugs. I guess we can ignore the last two for the moment (though, you should report them to LKML as they are, apparently, upstream bugs). For the others: There have been some fixes to the block layer in later versions, so could you please try to reproduce the relevant bugs (with tshark?) on a recent version and, if you can, open new issues -- one for each bug you hit? But just one more thought: All of your reports hint at memory related issues. Are you overclocking / overvolting your system? Or is the CPU overheating? Could you run a memory stress test like memtest86 on those systems? Those addresses and call traces just look too odd, so memory problems might be the real issue here. |
No, I'm not. (Related somewhat, old MBO firmware I have, as @HacKurx reported somewhere in my six report of which one is this, but I want more info on those... What if some PSP was enhanced, than I'm better of with the old MBO firmware, but where do I learn about those? Sorry!)
I will. As soon as I'm done with some other work. (Also: will study your new posts to my best, then. Thanks!) |
Just for completeness, about that I reported in the open bug where the above post by minipli was referenced: And the reply to this part
is explicitly: No! No means for new systems very often at all, I can't afford experimenting with overclocking / overvolting. Thanks again, @minipli ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
grsec-unoff RAP related Call Traces
http://www.croatiafidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/
Will be back to tell more, ask more...
The text was updated successfully, but these errors were encountered: