From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH] simfs: Fix reads beyond the first block
Date: Fri, 30 Jul 2021 11:08:44 -0500 [thread overview]
Message-ID: <a2b59a8d-4ba5-5b46-6f59-d3ec27cb7256@gmail.com> (raw)
In-Reply-To: <022b8cde-8fff-2802-697a-dbeb52aefa8c@jolla.com>
[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]
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
prev parent reply other threads:[~2021-07-30 16:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 12:07 [PATCH] simfs: Fix reads beyond the first block Slava Monich
2021-07-30 15:37 ` Denis Kenzior
2021-07-30 15:52 ` Slava Monich
2021-07-30 16:08 ` Denis Kenzior [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2b59a8d-4ba5-5b46-6f59-d3ec27cb7256@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).