| Message ID | 20240730080342.1814470-1-ross.lagerwall@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | bunzip2: fix rare decompression failure | expand |
On 30.07.2024 10:03, Ross Lagerwall wrote: > The decompression code parses a huffman tree and counts the number of > symbols for a given bit length. In rare cases, there may be >= 256 > symbols with a given bit length, causing the unsigned char to overflow. > This causes a decompression failure later when the code tries and fails to > find the bit length for a given symbol. > > Since the maximum number of symbols is 258, use unsigned short instead. > > Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> A Fixes: tag and maybe an Origin: one would have been nice; the latter just "maybe" because the Linux patch is one of yours anyway. Jan
On Tue, Jul 30, 2024 at 10:25 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 30.07.2024 10:03, Ross Lagerwall wrote: > > The decompression code parses a huffman tree and counts the number of > > symbols for a given bit length. In rare cases, there may be >= 256 > > symbols with a given bit length, causing the unsigned char to overflow. > > This causes a decompression failure later when the code tries and fails to > > find the bit length for a given symbol. > > > > Since the maximum number of symbols is 258, use unsigned short instead. > > > > Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> > > Acked-by: Jan Beulich <jbeulich@suse.com> > > A Fixes: tag and maybe an Origin: one would have been nice; the latter just > "maybe" because the Linux patch is one of yours anyway. > Indeed, I decided against an origin tag since I wasn't backporting someone else's change from Linux, just fixing the same thing in multiple places. I should have added a fixes tag. Here it is: Fixes: ab77e81f6521 ("x86/dom0: support bzip2 and lzma compressed bzImage payloads") Thanks, Ross
diff --git a/xen/common/bunzip2.c b/xen/common/bunzip2.c index 4466426941e0..79f17162b138 100644 --- a/xen/common/bunzip2.c +++ b/xen/common/bunzip2.c @@ -221,7 +221,8 @@ static int __init get_next_block(struct bunzip_data *bd) RUNB) */ symCount = symTotal+2; for (j = 0; j < groupCount; j++) { - unsigned char length[MAX_SYMBOLS], temp[MAX_HUFCODE_BITS+1]; + unsigned char length[MAX_SYMBOLS]; + unsigned short temp[MAX_HUFCODE_BITS+1]; int minLen, maxLen, pp; /* Read Huffman code lengths for each symbol. They're stored in a way similar to mtf; record a starting
The decompression code parses a huffman tree and counts the number of symbols for a given bit length. In rare cases, there may be >= 256 symbols with a given bit length, causing the unsigned char to overflow. This causes a decompression failure later when the code tries and fails to find the bit length for a given symbol. Since the maximum number of symbols is 258, use unsigned short instead. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> --- This issue was noticed in Linux decompressing initrds but since Xen has the same decompression code, it is possible the issue occurs here too. xen/common/bunzip2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)