The chances of the Linux kernel suddenly becoming completely unmaintained are so close to nil that it's not really worth considering.
But yes, if you're running something on top of Linux, and run into a kernel bug, you're of course free to report it, but the only guarantee is if you find and fix the bug yourself. None of those kernel developers are obligated to help you. In practice, many will want to help you! But that's not something anyone is entitled to.
I've worked at shops where there were people (myself included) who were capable of and occasionally had to dive into the kernel to fix issues. Often these were kernels coming from BSPs from some random chipset manufacturer, where the kernel was a year out of date and no Linux developer would want to touch it anyway. But even if we were running the absolute latest kernel version, we'd still probably dive in to investigate while reporting the issue upstream.
FWIW, here’s my actual view on this: there’s a great episode of the Oxide and Friends podcast where Brian & co. talk to Kelsey Hightower about Hashicorp changing the Terraform license to exclude a lot of companies in the TF ecosystem—the ultimate “we’re the maintainers we can do what we want” move. Kelsey has maintained many open source projects and understands the importance of maintainers having freedom to focus their energy where they see fit regardless of what the peanut gallery thinks.
His view, which I agree with, is that what is ultimately needed is upfront clarity from maintainers about how they’re going to govern the project. If you want to have complete control over your project and ignore bugs and pull requests as you see fit, and users need to accept the software as it is, that is fine and good, but put it in the README so that prospective users know what they’re getting into. If you want to have a community-driven governance structure where people have a path to getting involved and steering the project, like Kubernetes, that’s good too and you should lay all that out for users too. What Terraform did, where they cultivated community engagement in order to have this plugin ecosystem and then rug pulled those plugin authors by changing the license, “poisoned the well of open source” (his words) by giving the impression that OSS is inherently fickle and serious teams should be hesitant to use it because maintainers can and will break things carelessly. I worry that comments like the OP’s reinforce this impression.
Professionally, I am one of the developers of Pachyderm, which is an open-source version control and data pipelining tool.