That’s not how I understand these paragraphs on kernel.org:
The kernel will mark itself as ‘tainted’ when something occurs that might be relevant later when investigating problems. Don’t worry too much about this, most of the time it’s not a problem to run a tainted kernel; the information is mainly of interest once someone wants to investigate some problem, as its real cause might be the event that got the kernel tainted. That’s why bug reports from tainted kernels will often be ignored by developers, hence try to reproduce problems with an untainted kernel.
Note the kernel will remain tainted even after you undo what caused the taint (i.e. unload a proprietary kernel module), to indicate the kernel remains not trustworthy. That’s also why the kernel will print the tainted state when it notices an internal problem (a ‘kernel bug’), a recoverable error (‘kernel oops’) or a non-recoverable error (‘kernel panic’) and writes debug information about this to the logs dmesg outputs. It’s also possible to check the tainted state at runtime through a file in /proc/ .
So, if I understand your input correctly, the kernel being tainted is the reason so the issue cannot be reported, or further debugged, right?
My kernel was tainted because of this:
[callejonm@fedora Desktop]$ cat /proc/sys/kernel/tainted
[callejonm@fedora Desktop]$ ./kernel-chktaint
Kernel is "tainted" for the following reasons:
* externally-built ('out-of-tree') module was loaded (#12)
* unsigned module was loaded (#13)
For a more detailed explanation of the various taint flags see
Documentation/admin-guide/tainted-kernels.rst in the Linux kernel sources
Raw taint value as int/string: 12288/'G OE '