#73 closed defect (fixed)
RSync 3.09 (SHL) and Zip 3.0 (July 5th 2008), crash when they encounter a file that has a blank EA, with no data.
| Reported by: | Doug Bissett | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | *none | Version: | |
| Severity: | medium | Keywords: | |
| Cc: |
Description
I have encountered a few cases where a file has a blank EA, with no data, in the middle of the EA list (as shown by FM/2 edit Extended Attributes). RSync, and ZIP, both crash when they encounter such a file. See Crash.txt in RSYNCCRASH.zip for details, and a sample file.
I have not, yet, determined what is actually creating the EAs that cause the problem (see Crash,txt, which describes how I created the file), but neither program should crash when they encounter the problem. It appears that most programs simply drop all of the EAs when they encounter it.
Attachments (1)
Change History (9)
by , 9 years ago
| Attachment: | RSYNCCRASH.zip added |
|---|
comment:1 by , 9 years ago
comment:2 by , 7 years ago
comment:3 by , 7 years ago
Okay, I have it. I will try to properly test it in the next few days.
I assume this does nothing to fix ZIP. Thanks...
comment:4 by , 7 years ago
I don't know that status of your zip issue. Have you installed the most recent version of zip.exe available from the netlabs rpm? It could have a fix.
FWIW, if the rsync patches prove sufficiently stable. It's possible they could be applied to the zip.exe. I recommend you open a separate ticket for the zip trap. It's unlikely the zip maintainers are going to know that this ticket relates to a zip.exe.
comment:5 by , 7 years ago
I haven't been able to create a new defective file, but the fixed version does handle the supplied sample okay.
It seems to me that this should actually be a system wide fix, not just for RSync, but I will leave that up to you. ZIP is still broken.
comment:6 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:7 by , 7 years ago
@Steven would you mind to check in the sources here as well? Or at least attach a diff, so we could take care.
comment:8 by , 7 years ago
@diver, the diff is in the distro. I'll consider using the netlabs repo to host the patches in the future.
SHL reported:
This turns out to be a kernel defect in DosEnumAttribute. Given the broken EAs in the testcase, FEA2 list is not returned as documented, if more than 1 EA is returned. The result is a trap when the code attempts to dereference the oNextEntry pointer. I will update rsync to report this as an error which would have been the case if the kernel had detected the malformed EA data.
Now, if ZIP can be fixed...