If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you. A change is filtered through multiple developer and the kernel has some kind of smoke and consistency tests it is subject to. Also there are people and companies that compile their kernel from the master branch and run software on it.
No one's gonna ship Linux with a broken read syscall. And if there were tests, one could still ship a broken read syscall anyway.
Tests do not guarantee the absence of bugs.
Genuinely curious: why would a company ever do this?
Distro kernels are general purpose and include a lot of stuff you do not need.
A custom-configured kernel is much smaller and (consequently, theoretically) more secure.
A commenter below gave a good example of a company that would need to run a bleeding edge kernel (Red Hat). The vast majority of companies would never need to do that though.
This may work for most people, but not all. It's easier to get things fixed while developers still work on something, than weeks/months later. Also if you have not most-popular hardware/software configuration, testing done by others isn't necessarily sufficient for you.
And it sometimes is.
> If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you.
I've seen to many kernel bugs on new hardware to believe this is enough. Maybe not in read(), but still in something that should work. Throwing testing on users may have been acceptable in the past, but not anymore.
Yes, you do, because otherwise you will find that some change or new hardware will break it.