Hi Slava,
On 7/30/21 10:52 AM, Slava Monich wrote:
On 30/07/2021 18.37, Denis Kenzior wrote:
Hi Slava,
On 7/30/21 7:07 AM, Slava Monich wrote:
---
src/simfs.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
Funny how long this bug has been lurking around.
Until we finally had a crash on reading an icon or something out of SIM. Which
most SIMs apparently don't have or else it would've been noticed earlier.
Figured :)
diff --git a/src/simfs.c b/src/simfs.c
index 3d4f6283..cf770265 100644
--- a/src/simfs.c
+++ b/src/simfs.c
@@ -383,18 +383,18 @@ static void sim_fs_op_read_block_cb(const struct
ofono_error *error,
}
start_block = op->offset / 256;
- end_block = (op->offset + (op->num_bytes - 1)) / 256;
+ end_block = op->num_bytes ? (op->offset + op->num_bytes - 1) / 256 :
+ start_block;
Curious why this is needed? op->num_bytes should never be zero since it gets
set to the file length?
I admit that it's a bit paranoid, but op->num_bytes is assigned without checking
and I figured that it wouldn't hurt to do a check here. Feel free to drop this
part if it looks like too much of an overkill to you.
I'm all for being paranoid, but there's not much sense doing a round-trip to the
SIM for a 0 byte read. So I rather we catch this elsewhere.
There's some sanity checking of num_bytes being 0 once the file info has been
obtained. It should be reset to file length if it is zero, which is generally
what we want for simple binary files.
Invocations of ofono_sim_read_bytes() should probably sanity check the length if
they want to be fully paranoid.
I went ahead and applied this patch without this particular chunk.
Regards,
-Denis
_______________________________________________
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org
