diff options
| author | Oliver Smith-Denny <osde@microsoft.com> | 2025-02-13 12:52:00 -0800 |
|---|---|---|
| committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2025-02-14 06:58:07 +0000 |
| commit | bc664d1830c9446cb1d33b10a41e6b3d207997f1 (patch) | |
| tree | 8c0c5a332052487aaef27ed02244a5e52e83d250 /NetworkPkg/Udp4Dxe | |
| parent | 523dbb6d597b63181bba85a337d1f53e511f4822 (diff) | |
| download | edk2-master.tar.gz edk2-master.tar.bz2 edk2-master.zip | |
This reverts commit 58766a472932c485d41163b1746fb1d9e7984f07.
In edk2 commit 58766a4, validation of the two reserved FAT entries
was added.
However, it also checked the return of FatGetFatEntry to MAX_UINT32,
which is what FatGetFatEntry returns when it encounters an error,
e.g. not being able to read the disk. However, MAX_UINT32 is also a
valid value for the reserved FAT entries and under some conditions
these will be returned in the success case.
A FAT volume formatted with these valid values of the reserved FAT
entries will fail to boot an OS because the opening of the volume
will fail.
However, the reason FatGetFatEntry returns MAX_UINT32 is that most
other uses of the function are comparing it against the END_OF_CHAIN
mark, which MAX_UINT32 will trip and those functions will fail out.
Because this is a critical bug that can prevent OS booting and the
bug the original commit was solving was accounting for a bad FAT
filesystem formatting tool, this commit is reverted for now.
Future work will clean up FatGetFatEntry so that it returns an
EFI_STATUS, but that involves more work and this bug needs to be
resolved in the meantime.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Diffstat (limited to 'NetworkPkg/Udp4Dxe')
0 files changed, 0 insertions, 0 deletions