diff options
author | Jakub Kicinski <kuba@kernel.org> | 2024-10-16 04:43:11 +0300 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2024-10-16 04:43:11 +0300 |
commit | 2d859aff775df5486667aa895a7e4b9c2e98e348 (patch) | |
tree | d4680ce134db3b56d799c0ea59ca6d38e27f34fb /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 397006ba5d918f9b74e734867e8fddbc36dc2282 (diff) | |
parent | 18429e6e0c2ad26250862a786964d8c73400d9a0 (diff) | |
download | linux-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