Telegram desktop caused kernel crash?

W

wismos

i was using my pc as usual when i suddenly noticed that the system has froze, after which it proceeded to reboot and autoran savecore and crashinfo and generated a coredump and text file containing an analysis of the coredump, after i quick looked through the analysis of the coredump it seems telegram desktop is at responsible(crashinfo output attached below)

now that made me wonder how is it possible for an userspace application running as non-root to make the kernel crash rather then the kernel crashing the process to save the kernel from crashing? aren't there any mechanisms in freebsd to prevent such things from happening?

edit: on another note, crashinfo and savecore are amazing utilities, the fact that my system auto rebooted, autodumped a core and autoran utilities useful in debugging the crash on its own is amazing thing for me, it helps a lot in debugging things like these
 

Attachments

Not having looked at the attachments the most likely cause here is that the client did some graphics operation that the DRM driver didn't like. See whether the client has a switch to turn off hardware acceleration.
 
wismos said:
how is it possible for an userspace application running as non-root to make the kernel crash
Click to expand...
Because userspace application still requires kernel to handle its run - from memory, threads, locks, .. you name it. You can experience kernel panic if there's a bug in kernel implementation.

Quick look at the info shows that telegram-desktop did trigger the issue due to "sleeping thread holds process lock". Not all locks can be held when process is sleeping. Kernel paniced to avoid possible deadlock. But it's impossible to do more with such output.

However .. are you able to reproduce the issue ? If yes that would be a good starting point for PR.
 
_martin said:
Because userspace application still requires kernel to handle its run - from memory, threads, locks, .. you name it.
Click to expand...
That is, telegram, launched with limited privileges ("1001" in the dump), was able to shake the kernel?
And what is the FD field in the fstat command:
Code: 
poly     telegram-desktop 74542 root /             2 drwxr-xr-x    1024  r
Why is the root showing there?
 
Thank you. I see. After this, one might say, unique case, I begin to put all these ominous messengers out of the equation. Although, quite recently, I was still hanging out on Telegram.
 
cracauer@ said:
Not having looked at the attachments the most likely cause here is that the client did some graphics operation that the DRM driver didn't like. See whether the client has a switch to turn off hardware acceleration.
Click to expand...
unlike the rest, i915kms and drm don't have debugging symbols, how would i go around building them with debugging symbols in case i encounter the issue again

edit: and about hardware accel, the only option for hw accel is for video decoding, which i have disabled
 
_martin said:
However .. are you able to reproduce the issue ? If yes that would be a good starting point for PR.
Click to expand...
i haven't been able to reproduce it as of yet and honestly i don't even remember how that issue happened in the first place as at that point tg was in background and i wasn't interacting with it in any way
 
USerID said:
Thank you. I see. After this, one might say, unique case, I begin to put all these ominous messengers out of the equation. Although, quite recently, I was still hanging out on Telegram.
Click to expand...
That's a good rule in general. But even with the potentionally unsafe program you should be ok in this context (i.e. it definitely should not crash the kernel).

wismos said:
i haven't been able to reproduce it as of yet and honestly i don't even remember how that issue happened in the first place as at that point tg was in background and i wasn't interacting with it in any way
Click to expand...
Your actual coredump has all the information. But as it's from desktop it's very likely it has some private information in (e.g. browser history, ..). Trying to stress telegram out (start/exit in loop) would be great.
telegram might be just a victim of different issue but as it was the program that triggered the bug, and with information at hand, it's a good starting point.
 
wismos said:
edit: and about hardware accel, the only option for hw accel is for video decoding, which i have disabled
Click to expand...
If it's an Electron app or etc it might have environment variables or flags to disable HW acceleration (like --disable-gpu --disable-software-rasterizer). Discord with AMD GPUs used to be an issue with HW accel with Windows MPO (so Discord would cause the display driver to crash).
 
Espionage724 said:
If it's an Electron app or etc it might have environment variables or flags to disable HW acceleration (like --disable-gpu --disable-software-rasterizer). Discord with AMD GPUs used to be an issue with HW accel with Windows MPO (so Discord would cause the display driver to crash).
Click to expand...
It is also worth checking your video card drivers and system updates, as in some cases hardware acceleration problems may be due to driver incompatibility with specific applications.
 
wismos said:
i was using my pc as usual when i suddenly noticed that the system has froze, after which it proceeded to reboot and autoran savecore and crashinfo and generated a coredump and text file containing an analysis of the coredump, after i quick looked through the analysis of the coredump it seems telegram desktop is at responsible(crashinfo output attached below)
Click to expand...
You've discovered a bug in the FreeBSD kernel. Congratulations!

Please report the bug via the FreeBSD bug database. Kernel hackers don't check the forums for bug reports so unless you report the bug properly, it will remain unfixed and you won't get famous. For information on how to report the bug, start reading here: https://www.freebsd.org/support/

Kernel hackers may ask you to run some commands on the core dump in order to obtain extra information about the problem, so naturally you have to preserve it. Don't share it with others, though, as it may contain plenty of your private information.

wismos said:
now that made me wonder how is it possible for an userspace application running as non-root to make the kernel crash rather then the kernel crashing the process to save the kernel from crashing? aren't there any mechanisms in freebsd to prevent such things from happening?
Click to expand...
It's simple. If a userland app has a bug, the app will crash. If the kernel has a bug, the kernel will crash.

Your bug is about threads and locks. Bugs of this kind are very sensitive to timing and sequencing of operations so they are often very difficult to reproduce. However, there is enough information in your core file for a kernel hacker to either resolve the problem or at least make a very good guess about what caused it.
 
You must log in or register to reply here.
Back
Top