While going through their 5.15.3 log I did notice two changes, which made
me go check what else we might be missing. The series here is the result.
Linux has also updated zstd, but that includes a pretty large change which
I'm not ready to deal with right now. Them moving closer to the upstream
zstd sources is certainly a good thing, so I suppose sooner or later we
will want to follow them in doing so.

1: xz: add fall-through comments to a switch statement
2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations
3: decompressors: fix spelling mistakes
4: xz: avoid overlapping memcpy() with invalid input with in-place decompression
5: xz: fix spelling in comments
6: xz: move s->lzma.len = 0 initialization to lzma_reset()
7: xz: validate the value before assigning it to an enum variable

Jan

Jan Beulich writes ("[PATCH 0/7] (mainly) xz imports from Linux"):
> While going through their 5.15.3 log I did notice two changes, which made
> me go check what else we might be missing. The series here is the result.
> Linux has also updated zstd, but that includes a pretty large change which
> I'm not ready to deal with right now. Them moving closer to the upstream
> zstd sources is certainly a good thing, so I suppose sooner or later we
> will want to follow them in doing so.
> 
> 1: xz: add fall-through comments to a switch statement
> 2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations
> 3: decompressors: fix spelling mistakes
> 4: xz: avoid overlapping memcpy() with invalid input with in-place decompression
> 5: xz: fix spelling in comments
> 6: xz: move s->lzma.len = 0 initialization to lzma_reset()
> 7: xz: validate the value before assigning it to an enum variable

FTAOD I think none of these are critical bug fixes for 4.16.
Please let me know if I'm wrong.

In theory 4 is UB but in practice the result is presumably just wrong
answers.

Ian.

On 19.11.2021 15:25, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 0/7] (mainly) xz imports from Linux"):
>> While going through their 5.15.3 log I did notice two changes, which made
>> me go check what else we might be missing. The series here is the result.
>> Linux has also updated zstd, but that includes a pretty large change which
>> I'm not ready to deal with right now. Them moving closer to the upstream
>> zstd sources is certainly a good thing, so I suppose sooner or later we
>> will want to follow them in doing so.
>>
>> 1: xz: add fall-through comments to a switch statement
>> 2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations
>> 3: decompressors: fix spelling mistakes
>> 4: xz: avoid overlapping memcpy() with invalid input with in-place decompression
>> 5: xz: fix spelling in comments
>> 6: xz: move s->lzma.len = 0 initialization to lzma_reset()
>> 7: xz: validate the value before assigning it to an enum variable
> 
> FTAOD I think none of these are critical bug fixes for 4.16.
> Please let me know if I'm wrong.

Indeed, you're not wrong, and I intentionally didn't tag them that way. All
I wanted is to get them out rather than sit on them.

> In theory 4 is UB but in practice the result is presumably just wrong
> answers.

Like Linux did, the plan is to backport that and perhaps 7. But there's no
urgency.

Jan

Hi Jan,

> On 19 Nov 2021, at 10:20, Jan Beulich <jbeulich@suse.com> wrote:
> 
> While going through their 5.15.3 log I did notice two changes, which made
> me go check what else we might be missing. The series here is the result.
> Linux has also updated zstd, but that includes a pretty large change which
> I'm not ready to deal with right now. Them moving closer to the upstream
> zstd sources is certainly a good thing, so I suppose sooner or later we
> will want to follow them in doing so.
> 
> 1: xz: add fall-through comments to a switch statement
> 2: xz: fix XZ_DYNALLOC to avoid useless memory reallocations
> 3: decompressors: fix spelling mistakes
> 4: xz: avoid overlapping memcpy() with invalid input with in-place decompression
> 5: xz: fix spelling in comments
> 6: xz: move s->lzma.len = 0 initialization to lzma_reset()
> 7: xz: validate the value before assigning it to an enum variable
> 

For the whole serie

Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>

> Jan