DEBIAN-CVE-2022-49648

In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parsevardefs() if there is a problem allocating > vardefs.expr, the earlier vardefs.name is freed. > This free is duplicated by freevardefs() which frees > the rest of the list. However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed. If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] eventhisttriggerparse+0x206f/0x20e0 [<00000000ae70d2cc>] triggerprocessregex+0xc0/0x110 [<0000000066737a4c>] eventtriggerwrite+0x75/0xd0 [<000000007341e40c>] vfswrite+0xbb/0x2a0 [<0000000087fde4c2>] ksyswrite+0x59/0xd0 [<00000000581e9cdf>] dosyscall64+0x3a/0x80 [<00000000cf3b065c>] entrySYSCALL64afterhwframe+0x46/0xb0