Use readOrThrow to check error conditions of io.read()

[kevinbackhouse]

It is safer to use readOrThrow, because it checks against the scenario where reading from the file fails.

[piponazo]

LGTM, Thanks!

[piponazo]

@Mergifyio backport main

[mergify]

Command backport main: success

Backports have been created

• #1636 Use readOrThrow to check error conditions of io.read() (backport #1627) has been created for branch main

[tcullum-rh]

@kevinbackhouse how does this protect against read of uninitialized memory? I'm not intimately familiar with all of the inner workings of Exiv2, but looking at this, I see there is a length check of iIo.size() < 12, hardcoded len = 4 which seems fine. There is a read into data and data is never actually used, which seems to be just a seek basically. The only issue I could think of is that iIo could have uninitialized data somehow. I just don't see how a call to error() would prevent that, but I'm not often working on C++ either.

[piponazo]

Hi @tcullum-rh, I think you are right in your analysis. I did not notice the iIo.size() < 12 check at the beginning of the function, which should prevent any situation in which we try to read beyond the iOo reserved memory.

[kevinbackhouse]

@tcullum-rh: you are right, I misdiagnosed this. I just stepped through it in gdb and figured out what's going on. The poc is a 15 byte file, which is so short that it triggers an error in isCr2Type. Normally, these "is" functions (isCr2Type, isJpegType, etc.) rewind the file back to the beginning. But it looks like most of them don't bother if they get an EOF error.

So that's why the iIo.size() < 12 isn't working: the file hasn't been rewound back to the beginning. So the subsequent calls to iIo.read get EOF errors which are ignored.

Even though I misunderstood the bug, I think my fix is still the right thing to do. readOrThrow is safer than checking iIo.size(), due to the possibility that file position isn't zero.