According to this bug report, the first vulnerability can leak sensitive information.
But since it doesn't mention what information to leak, I guess it would be the stack? And how could this help in exploit development?
Usually, that kind of leak (reading a string which was not NULL-terminated) results in reading what happens to reside in RAM just after the string. Then this depends on where the string is. If the string is stack-allocated, then this discloses part of the stack (since stacks "grow down", this will explore local variables of callers of the current function). If the string is heap-allocated, then the reading will overflow in adjacent blocks, which can be about anything, depending on all previous allocations since last boot, so this is rather unpredictable.
There are some high-value targets in the kernel (e.g. encryption keys for in-kernel cryptographic operations). These targets can be in local variables, block-allocated objects... it really depends on the context. Simply reading the local stack can help a lot in fine tuning a buffer overflow exploit (a non-tuned buffer overflow leads to a crash, a tuned buffer overflow can lead to arbitrary code execution).
Most peeks at the kernel memory won't reveal anything of value, because 99.9% (at least) of memory used by some code (be it the kernel or some application) is not really confidential and could be revealed with no ill effect. However, it is very hard to precisely locate the remaining 0.1%: guaranteeing that a given piece of information is not sensitive is nigh infeasible in the general case. So it is safest to consider such information leak vulnerabilities as "potentially serious", and fix them.
In the kernel land, the ability to read memory addresses can undermine ASLR. Randomization is about secrets, and if you can read these secrets then ASLR isn't very helpful.
A simple example in the web app world is using error information disclosure to obtain a full path. With the full path you could use directory traversal to access the web root, or use mysql's