vfs/ext2: Incorrectly calculated nbytes_to_read in ext2_inode_read potentially causing data corruption

[de-nordic]

Describe the bug
Previous fix for issue 82933 has unfortunately brought in potential for
data corruption:

zephyr/subsys/fs/ext2/ext2_impl.c

Lines 628 to 634 in 3f6d78c

	size_t to_read = MIN(nbytes_to_read, MIN(left_on_blk, left_in_file));
	memcpy((uint8_t *)buf + read, inode_current_block_mem(inode) + block_off, to_read);
	read += to_read;
	nbytes_to_read -= read;
	offset += to_read;

Note that nbytes_to_read which is representing how many bytes are left to read, to some buffer as requested by user, by the whole operation is reduced each loop with value of read, which represents all data that has been so far read.
The nbytes_to_read should instead be decremented by to_read which is calculated as max data to read at given iteration, as bound by block size, file size or space left in user buffer.
What currently happens is that the nbytes_to_read is reduced in increasing pace which as a result makes it jump around size_t range, no longer tracking how many bytes are there left to read.
Above means that when user buffer is longer than blocks size and/or file at some point the line 628, that calculates bytes to read at given iteration, may incorrectly see nbytes_to_read as larger than MIN(left_on_blk, left_in_file), and being out of sync with nbytes read data, crossing over beyond the user buffer, with whatever of MIN(left_on_blk, left_in_file) is smaller.

• OS: Any
• Toolchain Zephyr SDK 0.16.3
• Commit SHA 3f6d78c

Additional context
Present in 4.0 via backport #83032
Present in 3.7 via backport #83031
Bug classified as medium due to having buffer/stack overflow and quite random nature.

Discovered by @CsBoBoNice