CVE-2019-14194 patch bypass

Hello.
I was analyzing CVE-2019-14194 and I think the patch can be bypassed. patch https://source.denx.de/u-boot/u-boot/-/commit/aa207cf3a6d68f39d64cd29057a4fb63943e9078
In nfs_read_reply, rlen is signed int. So we can make it less than zero. The value less than zero can bypass the check at line 756. This will lead to overflow due that assign has an unsigned int len parameter.
For example -1 will become 0xffffffff.
[image: nfs_read_reply_cve_2019_14194.png]
I've constructed some code to prove this.
[image: nfs_read_reply_cve_2019_14194_bypass.png]
[image: nfs_read_reply_cve_2019_14194_3.png]
Thanks.

On Wed, Aug 02, 2023 at 11:16:17PM +0300, sploit em wrote:
Hello.
I was analyzing CVE-2019-14194 and I think the patch can be bypassed. patch https://source.denx.de/u-boot/u-boot/-/commit/aa207cf3a6d68f39d64cd29057a4fb63943e9078
In nfs_read_reply, rlen is signed int. So we can make it less than zero. The value less than zero can bypass the check at line 756. This will lead to overflow due that assign has an unsigned int len parameter.
For example -1 will become 0xffffffff.
[image: nfs_read_reply_cve_2019_14194.png]
I've constructed some code to prove this.
[image: nfs_read_reply_cve_2019_14194_bypass.png]
[image: nfs_read_reply_cve_2019_14194_3.png]
Thanks.
Good find. A patch to resolve this issue, by someone with an eye towards other ways the problem could be exploited again so that this time we don't have other avenues of attack open, would be appreciated. Thanks.
participants (2)
-
sploit em
-
Tom Rini