[oe][meta-oe][PATCH 4/4] libvncserver: patch CVE-2026-50538

[ankur.tyagi85@gmail.com]

From: Ankur Tyagi <ankur.tyagi85@gmail.com>

Details:
https://nvd.nist.gov/vuln/detail/cve-2026-50538

Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
---
 .../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 <basdaniel3@gmail.com>
+(cherry picked from commit 540332be3e0acc566fa64da6f1b4680c72c724dd)
+
+CVE: CVE-2026-50538
+Upstream-Status: Backport [https://github.com/LibVNC/libvncserver/commit/540332be3e0acc566fa64da6f1b4680c72c724dd]
+Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
+---
+ 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"