You should interpret it as such, an untrusted input is able to write to section in memory that it isn't supposed to write because application fails to check its size.
I think you are in the mindset of always categorising RCE as extension of buffer overflow when they could be different issues altogether. Take for instance RCE due to remote file inclusion, or flaws in web applications that utilise eval in scripting languages or take untrusted input to run an OS command. These are RCEs but not necessarily BOF.
I guess what I'm saying is, a buffer overflow can be treated as its own category that describes what a vulnerability is and how it happens. It could potentially be extended to RCE or DoS, but overflow is quite perfect to understand it.
When you see an overflow vulnerability, you can always check associated publicly released exploit code and read more about it to see if there's DoS or RCE. Most (if not all) BOFs are at a minimum already DoS. Also, it is possible to read that an overflow leads to RCE, but you can't find any public exploit. This is common, especially in software that are proprietary. This doesn't mean that it's unconfirmed, its just that the researcher(s) never released to the public and may be part of proprietary security tools.