From 17464c3ed2284eb58062ef94b6fdd267be838080 Mon Sep 17 00:00:00 2001 From: Ankur Tyagi Date: Wed, 21 Oct 2026 00:03:57 +1300 Subject: [PATCH] libvncserver: patch CVE-2026-50538 Details: https://nvd.nist.gov/vuln/detail/cve-2026-50538 Signed-off-by: Ankur Tyagi Signed-off-by: Khem Raj --- .../libvncserver/CVE-2026-50538.patch | 49 +++++++++++++++++++ .../libvncserver/libvncserver_0.9.15.bb | 1 + 2 files changed, 50 insertions(+) create mode 100644 meta-oe/recipes-graphics/libvncserver/libvncserver/CVE-2026-50538.patch diff --git a/meta-oe/recipes-graphics/libvncserver/libvncserver/CVE-2026-50538.patch b/meta-oe/recipes-graphics/libvncserver/libvncserver/CVE-2026-50538.patch new file mode 100644 index 0000000000..da01736323 --- /dev/null +++ b/meta-oe/recipes-graphics/libvncserver/libvncserver/CVE-2026-50538.patch @@ -0,0 +1,49 @@ +From e824e7d8ea71feccb81aeb34771eb83e052c3fe2 Mon Sep 17 00:00:00 2001 +From: "Bas.Levering" <45083161+Bazskillz@users.noreply.github.com> +Date: Fri, 29 May 2026 09:08:28 +0200 +Subject: [PATCH] Merge commit from fork + +HandleTightBPP's basic-compression loop wrote each batch of decompressed +rows straight into client->frameBuffer (via FilterCopy/Palette/Gradient) +and only compared the running total against the rectangle height rh after +the loop. A malicious or man-in-the-middle server can send a zlib stream +that decompresses to more rows than rh, so the writes run past the end of +the framebuffer allocation: an attacker-controlled heap out-of-bounds +write reachable in a default build (Tight is advertised when built with +libz+libjpeg), pre-authentication, from one FramebufferUpdate. + +Clamp numRows to the remaining height before calling filterFn, matching +the existing house style (trle.c and the Tight JPEG path already clamp to +the rectangle height). + +Co-authored-by: Bas Levering +(cherry picked from commit 540332be3e0acc566fa64da6f1b4680c72c724dd) + +CVE: CVE-2026-50538 +Upstream-Status: Backport [https://github.com/LibVNC/libvncserver/commit/540332be3e0acc566fa64da6f1b4680c72c724dd] +Signed-off-by: Ankur Tyagi +--- + src/libvncclient/tight.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +diff --git a/src/libvncclient/tight.c b/src/libvncclient/tight.c +index dad5514f..3ee0d5e0 100644 +--- a/src/libvncclient/tight.c ++++ b/src/libvncclient/tight.c +@@ -341,6 +341,16 @@ HandleTightBPP (rfbClient* client, int rx, int ry, int rw, int rh) + + numRows = (bufferSize - zs->avail_out) / rowSize; + ++ /* The decompressed stream is server-controlled and may yield more rows ++ than the rectangle's declared height. filterFn() writes directly into ++ client->frameBuffer, so clamp here before writing to avoid running past ++ the framebuffer (heap out-of-bounds write). The post-loop ++ "rowsProcessed != rh" check happens too late. */ ++ if (numRows > rh - rowsProcessed) { ++ rfbClientLog("Tight: too many scan lines after decompression.\n"); ++ return FALSE; ++ } ++ + filterFn(client, rx, ry+rowsProcessed, numRows); + + extraBytes = bufferSize - zs->avail_out - numRows * rowSize; diff --git a/meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.15.bb b/meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.15.bb index e2f995947f..ff7327c6cf 100644 --- a/meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.15.bb +++ b/meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.15.bb @@ -49,6 +49,7 @@ SRC_URI = "git://github.com/LibVNC/libvncserver;branch=master;protocol=https;tag file://CVE-2026-44988.patch \ file://CVE-2026-32854.patch \ file://CVE-2026-32853.patch \ + file://CVE-2026-50538.patch \ " SRCREV = "9b54b1ec32731bd23158ca014dc18014db4194c3"