summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorFeng Tang <feng.tang@intel.com>2024-10-16 17:41:51 +0200
committerVlastimil Babka <vbabka@suse.cz>2024-11-16 21:19:08 +0100
commit5474d33ca48e7764ccc38b2ac089863cca83280a (patch)
tree7a724a89115e7207f6e82fa77e0963dd90f287d1 /lib
parentmm/slub: Consider kfence case for get_orig_size() (diff)
downloadlinux-5474d33ca48e7764ccc38b2ac089863cca83280a.tar.xz
linux-5474d33ca48e7764ccc38b2ac089863cca83280a.zip
mm/slub: Improve redzone check and zeroing for krealloc()
For current krealloc(), one problem is its caller doesn't pass the old request size, say the object is 64 bytes kmalloc one, but caller may only requested 48 bytes. Then when krealloc() shrinks or grows in the same object, or allocate a new bigger object, it lacks this 'original size' information to do accurate data preserving or zeroing (when __GFP_ZERO is set). Thus with slub debug redzone and object tracking enabled, parts of the object after krealloc() might contain redzone data instead of zeroes, which is violating the __GFP_ZERO guarantees. Good thing is in this case, kmalloc caches do have this 'orig_size' feature. So solve the problem by utilize 'org_size' to do accurate data zeroing and preserving. [Thanks to syzbot and V, Narasimhan for discovering kfence and big kmalloc related issues in early patch version] Suggested-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Feng Tang <feng.tang@intel.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions