I used to think that all Valgrind errors were bugs too..
Until I started running valgrind on the popular GNU tools like ps, ls, top, etc and found Valgrind errors that appeared to be memory leaks.
Turned out, that Valgrind was complaining about some memory that wasn't explicitly being freed in code, but it doesn't matter because the memory is automatically freed when the process terminates. Adding code to explicitly free that memory would do nothing but delay the process's termination of a process that's ready to terminate, so the bug reports were closed and I learned to take Valgrind problems a lot less seriously.
Valgrind is useful in tracking down problems when you know there is a problem, but can also generate a massive amount of false positives and the few positives that it does have will often be multipled by 10,000x for the same line of code.
Edit: And also as mentioned, the kernel has got IO controlls that work with memory in ways that Valgrind doesn't know about / understand properly and so will result in a large number of false positives.. You need to filter out all the possible false positives from the ioctrls first, otherwise you're not really helping much. There's no way a dev is going to go through all those valgrind errors manually to find out if they're duplicate or not, or invalid or not. You should do it for them to narrow down the problem to code that actually might have a problem. It's part of the process of making a good bug report. Making good bug reports with Valgrind is hard unless you understand it well, RTFM, filter out the massive amount of false positives and then try again.