summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2024-10-16 04:43:11 +0300
committerJakub Kicinski <kuba@kernel.org>2024-10-16 04:43:11 +0300
commit2d859aff775df5486667aa895a7e4b9c2e98e348 (patch)
treed4680ce134db3b56d799c0ea59ca6d38e27f34fb /tools/perf/scripts/python/export-to-postgresql.py
parent397006ba5d918f9b74e734867e8fddbc36dc2282 (diff)
parent18429e6e0c2ad26250862a786964d8c73400d9a0 (diff)
downloadlinux-2d859aff775df5486667aa895a7e4b9c2e98e348.tar.xz
Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'
Ignat Korchagin says: ==================== do not leave dangling sk pointers in pf->create functions Some protocol family create() implementations have an error path after allocating the sk object and calling sock_init_data(). sock_init_data() attaches the allocated sk object to the sock object, provided by the caller. If the create() implementation errors out after calling sock_init_data(), it releases the allocated sk object, but the caller ends up having a dangling sk pointer in its sock object on return. Subsequent manipulations on this sock object may try to access the sk pointer, because it is not NULL thus creating a use-after-free scenario. We have implemented a stable hotfix in commit 631083143315 ("net: explicitly clear the sk pointer, when pf->create fails"), but this series aims to fix it properly by going through each of the pf->create() implementations and making sure they all don't return a sock object with a dangling pointer on error. ==================== Link: https://patch.msgid.link/20241014153808.51894-1-ignat@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions