Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
Hi Michael, On Fri, Apr 03, 2026 at 06:55:27PM +0300, Michael Tokarev wrote: > On Sat, 28 Mar 2026 21:07:22 +0300 Michael Tokarev wrote: > > On 28.03.2026 19:07, Jonathan Wiltshire wrote: > > > Control: tag -1 confirmed > > > > Hi, > > > > I am fine with everything you propose. Please go ahead. > > > > Thank you! Uploaded. > > > > Please note: there's another 2 batches of CVE fixes in 3.24.0 and 3.24.2 > > versions of freerdp, which are not included in this upload, - I'll > > prepare another one, hopefully anyway. > Hi! > > I updated the package to include more security fixes from the upstream, > as has been mentioned earlier. > > Debdiff against the previous upload is below, version > 3.15.0+dfsg-2.1+deb13u2 > > I dunno if it is better to combine it this with the previous upload or > to have 2 different uploads like it is now - I'm okay either way, just > tell me how it is easier for you. I probably should update subject to > reflect the version, if it should be new version. > > As before, this release is verified just by using the tools provided, - > which had me to pick a few more fixes so it works correctly. So it'd > be better if this upload be available in trixie-proposed-updates for a > while before becoming an official part of debian trixie. I'm not a SRM, so do not take this as an authoritative answer. But my gut feeling here is as follows: The earlier change was acked and requested to be uploaded, which you did, while it yet still in freerdp3 | 3.15.0+dfsg-2.1+deb13u1 | stable-new| source I would actually decouple the new followup update with a new bugreport and leaving this one for 3.15.0+dfsg-2+deb13u1. So open a new one to build on top 3.15.0+dfsg-2+deb13u2. But again, I'm not authoritatively speaking here. Regards, Salvatore
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On Sat, 28 Mar 2026 21:07:22 +0300 Michael Tokarev wrote: On 28.03.2026 19:07, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > Hi, > > I am fine with everything you propose. Please go ahead. Thank you! Uploaded. Please note: there's another 2 batches of CVE fixes in 3.24.0 and 3.24.2 versions of freerdp, which are not included in this upload, - I'll prepare another one, hopefully anyway. Hi! I updated the package to include more security fixes from the upstream, as has been mentioned earlier. Debdiff against the previous upload is below, version 3.15.0+dfsg-2.1+deb13u2 I dunno if it is better to combine it this with the previous upload or to have 2 different uploads like it is now - I'm okay either way, just tell me how it is easier for you. I probably should update subject to reflect the version, if it should be new version. As before, this release is verified just by using the tools provided, - which had me to pick a few more fixes so it works correctly. So it'd be better if this upload be available in trixie-proposed-updates for a while before becoming an official part of debian trixie. Thanks, /mjtdiff -Nru freerdp3-3.15.0+dfsg/debian/changelog freerdp3-3.15.0+dfsg/debian/changelog --- freerdp3-3.15.0+dfsg/debian/changelog 2026-03-28 20:59:33.0 +0300 +++ freerdp3-3.15.0+dfsg/debian/changelog 2026-04-03 18:45:10.0 +0300 @@ -1,3 +1,72 @@ +freerdp3 (3.15.0+dfsg-2.1+deb13u2) trixie; urgency=medium + + * security fixes for client from 3.24.0 (medium): + +CVE-2026-29774 Heap-buffer-overflow in avc420_yuv_to_rgb via OOB regionRects + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-5q35-hv9x-7794 + codec-h264-validate-rectangles-before-use-CVE-2026-29774.patch +CVE-2026-29775 Heap-buffer-overflow in bitmap_cache_put via OOB cacheId + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-h666-rfw3-jhvj + cache-bitmap-overallocate-bitmap-cache-CVE-2026-29775.patch +CVE-2026-29776 Integer Underflow in update_read_cache_bitmap_order + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-c747-x4wf-cqrr + core-order-fix-const-correctness.patch + core-orders-improve-input-validation-CVE-2026-29776.patch +CVE-2026-31806 Heap Buffer Overflow in nsc_process_message() via Unchecked + SURFACE_BITS_COMMAND Bitmap Dimensions + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-rrqm-46rj-cmx2 + codec-nsc-bounds-checks-and-doxygen.patch + codec-nsc-log-decoder-function-parameter-issues.patch + codec-nsc-fix-use-of-nsc_process_message.patch + codec-nsc-limit-copy-area-in-nsc_process_message-CVE-2026-31806.patch +CVE-2026-31883 `size_t` underflow in ADPCM decoder leads to + heap-buffer-overflow write + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-85x9-4xxp-xhm5 +CVE-2026-31885 Out-of-bounds read in ADPCM decoders due to + missing predictor/step_index bounds checks + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-85x9-4xxp-xhm5 + codec-dsp-fix-array-bounds-checks-CVE-2026-31883-CVE-2026-31885.patch +CVE-2026-31884 Division-by-zero in ADPCM decoders when `nBlockAlign` is 0 + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-jp7m-94ww-p56r + codec-dsp-add-format-checks-CVE-2026-31884.patch +CVE-2026-31897 Out-of-bounds read in `freerdp_bitmap_decompress_planar` + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-xgv6-r22m-7c9x + codec-planar-add-early-length-check-to-avoid-oob-rea-CVE-2026-31897.patch + + * security fixes for client from 3.24.2 (medium): + +CVE-2026-33952 DoS via WINPR_ASSERT in + rts_read_auth_verifier_no_checks (rts.c:282) + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-4v4p-9v5x-hc93 + core-gateway-Check-rpcconn_common_hdr_t-auth_length--CVE-2026-33952.patch +CVE-2026-33977 DoS via WINPR_ASSERT in IMA ADPCM audio decoder (dsp.c:331) + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-8f2g-3q27-6xm5 + codec-dsp-fix-IMA-ADPCM-sample-clamping-CVE-2026-33977.patch +CVE-2026-33995 double free in kerberos_AcceptSecurityContext + and kerberos_IntitalizeSecurityContextA + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-mv25-f4p2-5mxx + winpr-sspi-Fix-context-nullptr-handling-CVE-2026-33995.patch +CVE-2026-33984 ClearCodec resize_vbar_entry() Heap OOB Write + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-8469-2xcx-frf6 + codec-clear-update-CLEAR_VBAR_ENTRY-size-after-alloc-CVE-2026-33984.patch +CVE-2026-33983 Progressive Codec Quant BYTE Underflow - UB + CPU DoS + https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-4gfm-4p52-h478 + codec-progressive-Fail-progressive_rfx_quant_sub-on--CVE-2026-33983.patch +CVE-2026-33985 ClearCodec Glyph Cache Count Desync - Heap OOB Read + https:
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On 28.03.2026 19:07, Jonathan Wiltshire wrote: Control: tag -1 confirmed Hi, I am fine with everything you propose. Please go ahead. Thank you! Uploaded. Please note: there's another 2 batches of CVE fixes in 3.24.0 and 3.24.2 versions of freerdp, which are not included in this upload, - I'll prepare another one, hopefully anyway. I do admire and value your dedication with this one, it's just that there are only two of us and we both have busy external lives so reviews sometimes take a little time. In this case, the problem wasn't really the time required for the review - I understand this one is really difficult to review because of the huge list of changes, - it's objectively complex. It is a complete lack of any feedback at all, even a very short "have no time to review" or "don't expect answer soon", or anything. I tried to be in time for 13.4, but whole approach is questionable exactly because it's a huge amount of changes. I also asked multiple times on IRC, if I can make things easier for review, - that stuff. Got no answer there too. I do all my Debian work in spare time only, unpaid, - just because I feel it's normal to give something in return to goods I'm using every day. And I too, have a lot of other things to do, and am sometimes quite busy. So I understand how things can be in this context. Time is our most valuable resource. Thank you for your time! /mjt
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
Control: tag -1 confirmed Hi, I am fine with everything you propose. Please go ahead. I do admire and value your dedication with this one, it's just that there are only two of us and we both have busy external lives so reviews sometimes take a little time. Thanks, -- Jonathan Wiltshire [email protected] Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On Wed, 25 Feb 2026 23:51:48 +0300 Michael Tokarev wrote: So, after some more time, another list of freerdp security issues has been identified and fixed. And I updated the proposed package with the new fixes. It now has 74 patches in total. Hi! The next trixie point release is expected to be tomorrow. I spent huge amount of time and resources preparing these updates. It took me about 3 whole *days* to pick up patches for the trixie version. I spend more amount of time testing it all and ensuring it works still. I think it deserves a tiny bit more attention and feedback from the release team -- even if the release team is busy with other things - than exactly nothing. Void is the most unexpected reaction to me. If this work is useless - I'm fine with that. If this work is useful, - ok, it is excellent, I did hope to fix issues for the trixie users and it worked. But void is.. it doesn't feel right. This is really discoraging. And depressing. Thanks for listening. /mjt
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On 2/9/26 20:09, Salvatore Bonaccorso wrote: I think they should be fixed via the next point release, but have an upload ideally accepted early to give it exposure to testers for regressions. Yeah, it's my view as well. A minor nitpick: You cannot choose 3.15.0+dfsg-2+deb13u1 as version as 3.15.0+dfsg-2.1 is the version which is in stable. So that would be 3.15.0+dfsg-2.1+deb13u1 . Um. That's why I didn't want the NMU. Can't it be ..-2.2 instead? :) But ok. Thanks, /mjt
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
Hi, On Mon, Feb 09, 2026 at 04:24:06PM +0300, Michael Tokarev wrote: > Package: release.debian.org > Severity: normal > Tags: trixie > X-Debbugs-Cc: [email protected], [email protected] > Control: affects -1 + src:freerdp3 > User: [email protected] > Usertags: pu > > [ Reason ] > Initially there were 2 bugfixes for 2 severity-important bugs > from the BTS, plus retoration of freerdp icon display, and I > thought about pushing this release for 13.3. > > However, a large number of security fixes come in. > > So in addition to the above 3 fixes, there are also fixes for 29 > security issues, plus a small number of preparational patches, - > all picked up from the upstream git repository. > > The complete debdiff is over 400Kb in size. > I'm sorry for it being so large, but here we go. > > The list of actual security fixes with the links to complete > descriptions are in the changelog, below. > > This update should close all security issues found and later > fixed in forky. > > While picking up upstream fixes, I also picked up a few other > changes in the same areas, so the fixes applies cleanly and > don't require back-porting. In most such cases, the other > changes are harmless - like improving logging or rearranging > code a tiny bit to be less obscure - like clang-warnings-fix-Wjump- > misses-init-*.patch. In my opinion, in this case, such extra > changes does not hurt at all, but makes the actual fix to apply > cleanly and avoids extra possible mistakes while back-porting. > > One change, however, is more than that: this is a preparational > patch for CVE-2026-24677, rdpecam-fix-camera-sample-grabbing.patch. > It is a bugfix by its own, so I decided to pick it up too, since > it changes code in this area quite significantly, and back-porting > later fix becomes a real challenge. This patch should not do any > harm. > > [ Impact ] > This is a really large number of security issues, most of which > is about a malicious RDP server doing bad things. Even if in > many cases, the RDP server where a user connects to, can be sort > of trusted, it's not a good thing to have bug in this area. > > [ Tests ] > There aren't much testing done for this (huge) release. I only > verified the main xfreerdp3 client works in basic scenarious - > personally I use this release myself to access several versions > of windows RDP servers, it continues working as expected. > > There's one correction already, on top of CVE-2026-24491, which is > also included in this release, but it was found quite fast, and I > found it missing in my testing of the debian package. > > I haven't checked more advanced functionality though. Also, I > checked usage of the freerdp-client shared library only briefly > (with Gnome Connections). > > [ Risks ] > The risks with this release is relatively high, due to the large > amount of fixes being back-ported after a large number of other > changes in the code. So there's a trade-off between risks and > security issues. > > Due to this reason, it would be best if this release will sit in > trixie-proposed-updates for a while. > > [ Checklist ] > [x] *all* changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in (old)stable > [x] the issue is verified as fixed in unstable > > [ Changes ] > See the top of debdiff. > > [ Other info ] > Since this release is mostly about security fixes, it might also > be worth considering pushing this through trixie-security. But > at the same time, due to relatively high risk of breaking something, > it might not be a good idea. Either way, I'm Cc'ing the Security > Team. I think they should be fixed via the next point release, but have an upload ideally accepted early to give it exposure to testers for regressions. A minor nitpick: You cannot choose 3.15.0+dfsg-2+deb13u1 as version as 3.15.0+dfsg-2.1 is the version which is in stable. So that would be 3.15.0+dfsg-2.1+deb13u1 . Regards, Salvatore
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On 2/9/26 17:04, Adrian Bunk wrote: On Mon, Feb 09, 2026 at 04:35:28PM +0300, Michael Tokarev wrote: ... 2. The fixes in there introduce two new symbols in shared libraries which appeared in much later versions of the library - 3.20 or 3.21. These new symbols are used internally by freerdp binaries, no existing-in-trixie clients, obviously, don't use these. I can't just add these symbols to the trixie shared libs with min version being current trixie one, because there's a version gap when this symbol doesn't exist. So I use a trick by providing a virtual package with these symbols for trixie, and use alternative dependency - either this virtual package or recent-enough library where this symbol actually appeared. ... New symbols are more common in pu updates than you might imagine, including in core packages like python3. Just using 3.15.0+dfsg-2+deb13u1~ as symbol version for the new symbols would be the normal solution. The version gap does technically exist, but only when upgrading to older versions from testing/unstable AND having a (local) package that is using the symbol installed - this is a pretty theoretical issue. I am not a member of the release team and I am not saying that what you are doing is wrong, but it is not really necessary or usually done. Adding to that. I spotted error in the versioning there -- https://salsa.debian.org/debian-remote-team/freerdp3/-/commit/070825727652dffdee4a77316d010efdb05ab745 mixes 3.22 vs 3.21. And, since nothing complains, I started looking more closely, and realized these symbols are only used inside the library (libfreerdp3-3 in this case) - it isn't used even in other binaries of the same package. Just inside the library which provides these symbols. So yes, it might be unnecessary in this case. And yes, I fixed the error in there, still providing the virtual package. I can drop this one as an unnecessary complication. I haven't faced such situation before, so thought I'd be cautious. Thanks, /mjt
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On Mon, Feb 09, 2026 at 04:35:28PM +0300, Michael Tokarev wrote: >... > 2. The fixes in there introduce two new symbols in shared libraries >which appeared in much later versions of the library - 3.20 or 3.21. >These new symbols are used internally by freerdp binaries, no >existing-in-trixie clients, obviously, don't use these. >I can't just add these symbols to the trixie shared libs with >min version being current trixie one, because there's a version >gap when this symbol doesn't exist. > >So I use a trick by providing a virtual package with these >symbols for trixie, and use alternative dependency - either >this virtual package or recent-enough library where this >symbol actually appeared. >... New symbols are more common in pu updates than you might imagine, including in core packages like python3. Just using 3.15.0+dfsg-2+deb13u1~ as symbol version for the new symbols would be the normal solution. The version gap does technically exist, but only when upgrading to older versions from testing/unstable AND having a (local) package that is using the symbol installed - this is a pretty theoretical issue. I am not a member of the release team and I am not saying that what you are doing is wrong, but it is not really necessary or usually done. > Thanks, > > /mjt cu Adrian
Bug#1127479: trixie-pu: package freerdp3/3.15.0+dfsg-2+deb13u1
On 2/9/26 16:24, Michael Tokarev wrote: [ Other info ] I forgot to mention 3 things. 1. Upstream does not consider patching previous releases of freerdp, treating a new upstream version as a fix for previous issues. This is why I'm keeping freerdp3 in trixie-backports up to date. 2. The fixes in there introduce two new symbols in shared libraries which appeared in much later versions of the library - 3.20 or 3.21. These new symbols are used internally by freerdp binaries, no existing-in-trixie clients, obviously, don't use these. I can't just add these symbols to the trixie shared libs with min version being current trixie one, because there's a version gap when this symbol doesn't exist. So I use a trick by providing a virtual package with these symbols for trixie, and use alternative dependency - either this virtual package or recent-enough library where this symbol actually appeared. 3. Current packaging is available in git on salsa, see debian/trixie branch https://salsa.debian.org/debian-remote-team/freerdp3/-/commits/debian/trixie This one might be easier to review than a huge debdiff. Thanks, /mjt
