Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pagekitec: add patch to fix use after free leading to segfault #24982

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion net/pagekitec/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=pagekitec
PKG_REV:=0.91.201110
PKG_VERSION:=$(PKG_REV)C
PKG_RELEASE:=2
PKG_RELEASE:=3
PKG_LICENSE:=Apache-2.0
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
Expand Down
45 changes: 45 additions & 0 deletions net/pagekitec/patches/0003-fix-use-after-free-in-pkproto.c.patch
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
From ef75e4d5e517ed12d6057b2211d401fa1ce84f4a Mon Sep 17 00:00:00 2001
From: Lukas Zeller <[email protected]>
Date: Tue, 17 Sep 2024 00:53:40 +0200
Subject: [PATCH] pkproto.c: fix use-after-free that did cause pagekite to
SIGSEGV occasionally, with higher probability on faster/multicore systems

Observation:
- programs using libpagekitec did crash with SIGSEGV on startup on RPi3,4
while having worked fine for years on RPi1+2

Explantation:
- the final "judgement" test were done on pointers into the `copy` buffer
freed on line 766 instead of on the safe copies of those strings in `kite`
and `kite_r`.
- this opened a very short race condition window, however the crash was
caught happening while a tight loop (`pkb_start_blockers`) fired up 16
of those threads in rapid succession.
So probably if the next thread got to allocate memory before the
"judgements" tests, accessing the just freed `copy` would cause a segfault.

Fix:
- check the safe copies of the strings instead of pointers into freed `copy`.

Signed-off-by: Lukas Zeller <[email protected]>
---
libpagekite/pkproto.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libpagekite/pkproto.c b/libpagekite/pkproto.c
index 3d4ccd6..4ee7e0f 100644
--- a/libpagekite/pkproto.c
+++ b/libpagekite/pkproto.c
Comment on lines +31 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch is part of upstream repository or it was sent to upstream?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet part of upstream, but I made a PR: pagekite/libpagekite#79

But as it is a total dealbreaker for pagekite remote maintainance when it hits (and it does for example on Rpi 3), I had to fix it for my builds immediately and independently of the upstream integration timeline, and decided sharing the openwrt level patch makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you backport the patch from this url: https://patch-diff.githubusercontent.com/raw/pagekite/libpagekite/pull/79.patch ? I just added .patch to the URL and keep the patch as it is? I mean, it adds Git header to this current situation. The Git header includes important details like who created the patch, who does those changes, commit subject, commit description, etc?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @BKPepe, I just updated the PR so that the patch within does contain the git headers.

Originally I created the patch using quilt configured as recommended for the "preferred format", apparently this is out of sync with current recommended format. Of course it makes total sense to have the context in the patch itself and not only in the metapatch.

@@ -766,9 +766,9 @@ char *pk_parse_kite_request(
free(copy);

/* Pass judgement */
- if ('\0' == *public_domain) return pk_err_null(ERR_PARSE_NO_KITENAME);
- if ('\0' == *bsalt) return pk_err_null(ERR_PARSE_NO_BSALT);
- if ('\0' == *fsalt) return pk_err_null(ERR_PARSE_NO_FSALT);
+ if ('\0' == *(kite->public_domain)) return pk_err_null(ERR_PARSE_NO_KITENAME);
+ if ('\0' == *(kite_r->bsalt)) return pk_err_null(ERR_PARSE_NO_BSALT);
+ if ('\0' == *(kite_r->fsalt)) return pk_err_null(ERR_PARSE_NO_FSALT);
return kite->public_domain;
}

Loading