Note that on i386 this introduces a new 2GB limit, but this is not a concern in practice. Also avoid allocating an extra byte in the old and new file content buffers.
Based on the "NON-CRYPTANALYTIC ATTACKS AGAINST FREEBSD UPDATE COMPONENTS" gist.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| usr.bin/bsdiff/bspatch/bspatch.c | ||
|---|---|---|
| 76–77 ↗ | (On Diff #19599) | On i386 ssize_t is 4 bytes, so would truncate from offtin / lseek. |
| 123 ↗ | (On Diff #19599) | SSIZE_MAX introduces a 2G limit, but we already had an implicit 2G limit for proper operation based on the previous newsize type. |
| 155 ↗ | (On Diff #19599) | Same 2G argument as above. |
Comment Actions
Changes seem fine to me. This code is really ugly, though.
| usr.bin/bsdiff/bspatch/bspatch.c | ||
|---|---|---|
| 175 ↗ | (On Diff #19679) | The gist checks for newsize <= 0. Is zero a valid newsize? |
| usr.bin/bsdiff/bspatch/bspatch.c | ||
|---|---|---|
| 175 ↗ | (On Diff #19679) | Yes, a zero byte output file is legitimate. |