Bug#867581: libgnutls30: AES256-GCM emits all-zeros ciphertext on aarch64 with hardware acceleration (upstream bug report)
Package: libgnutls30
Version: 3.5.8-5+deb9u1
Severity: critical
Tags: patch
Justification: breaks unrelated software
Dear Maintainer,
* What led up to the situation?
Unrelated gnome-terminal or xfce4-terminal crashing when significant output
(e.g. running 'yes'; apparently because of the corruption of the encrypted
scrollback buffer).
Issue noticed on a Cavium ThunderX running Debian Stretch.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Patching libgnutls with
https://gitlab.com/gnutls/gnutls/commit/228b18dfbf934d8924d3305dc24d7b0162352eba
fixes the issue.
This fix is available in gnutls 3.5.13 (and testing+unstable) but not in 3.5.8
(stable). Please back-port the above patch to stable.
Upstream bug report: https://gitlab.com/gnutls/gnutls/issues/204
I marked it as 'critical' because it breaks unrelated packages, though I'm not
sure that's the appropriate severity level.
Thanks.
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.9.0-3-arm64 (SMP w/48 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libgnutls30 depends on:
ii libc62.24-11+deb9u1
ii libgmp10 2:6.1.2+dfsg-1
ii libhogweed4 3.3-1+b1
ii libidn11 1.33-1
ii libnettle6 3.3-1+b1
ii libp11-kit0 0.23.3-2
ii libtasn1-6 4.10-1.1
ii zlib1g 1:1.2.8.dfsg-5
libgnutls30 recommends no packages.
Versions of packages libgnutls30 suggests:
pn gnutls-bin
diff --git a/lib/accelerated/aarch64/aes-gcm-aarch64.c
b/lib/accelerated/aarch64/aes-gcm-aarch64.c
index c571d02..8d2bc1d 100644
--- a/lib/accelerated/aarch64/aes-gcm-aarch64.c
+++ b/lib/accelerated/aarch64/aes-gcm-aarch64.c
@@ -153,6 +153,27 @@ gcm_ghash(struct aes_gcm_ctx *ctx, const uint8_t * src,
size_t src_size)
}
static void
+ctr32_encrypt_blocks_inplace(const unsigned char *in, unsigned char *out,
+size_t blocks, const AES_KEY *key,
+const unsigned char ivec[16])
+{
+ unsigned i;
+ uint8_t ctr[16];
+ uint8_t tmp[16];
+
+ memcpy(ctr, ivec, 16);
+
+ for (i=0;i
Bug#863798: linux-image-4.9.0-3-arm64: Enable CONFIG_DRM_RADEON=m in the arm64 kernel config
Package: src:linux Version: 4.9.25-1 Severity: wishlist Tags: newcomer Dear Maintainer, * What led up to the situation? ARMv8 desktop system with a Radeon graphics card running Debian (stretch). * What exactly did you do (or not do) that was effective (or ineffective)? Added CONFIG_DRM_RADEON=m to debian/config/arm64/config in the linux-4.9.25 source package and rebuilt the deb package. * What was the outcome of this action? Video output works. No further action necessary. -- Package-specific info: ** Version: Linux version 4.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.25-1 (2017-05-02) ** Command line: BOOT_IMAGE=/vmlinuz-4.9.0-3-arm64 root=/dev/mapper/armageddon--vg-root ro ** Not tainted ** Kernel log: [ 12.205626] [drm] initializing kernel modesetting (OLAND 0x1002:0x6608 0x103C:0x2120 0x00). [ 12.214015] [drm] register mmio base: 0x1000 [ 12.218652] [drm] register mmio size: 262144 [ 12.350800] Adding 32088060k swap on /dev/mapper/armageddon--vg-swap_1. Priority:-1 extents:1 across:32088060k SSFS [ 12.447985] ATOM BIOS: Hadron [ 12.453023] [drm] GPU not posted. posting now... [ 12.465670] radeon 0005:90:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) [ 12.474555] radeon 0005:90:00.0: GTT: 2048M 0x8000 - 0x [ 12.482220] [drm] Detected VRAM RAM=2048M, BAR=256M [ 12.487099] [drm] RAM width 128bits DDR [ 12.491048] [TTM] Zone kernel: Available graphics memory: 16430186 kiB [ 12.497678] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 12.497684] [TTM] Initializing pool allocator [ 12.497697] [TTM] Initializing DMA pool allocator [ 12.497750] [drm] radeon: 2048M of VRAM memory ready [ 12.497752] [drm] radeon: 2048M of GTT memory ready. [ 12.497788] [drm] Loading oland Microcode [ 12.498423] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_pfp.bin [ 12.498836] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_me.bin [ 12.499104] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_ce.bin [ 12.499384] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_rlc.bin [ 12.499970] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_mc.bin [ 12.500513] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/oland_smc.bin [ 12.500525] [drm] Internal thermal controller with fan control [ 12.500661] [drm] probing gen 2 caps for device 177d:a100 = 735c83/e [ 12.509345] [drm] radeon: dpm initialized [ 12.510307] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin [ 12.510847] radeon 0005:90:00.0: firmware: direct-loading firmware radeon/TAHITI_vce.bin [ 12.512137] [drm] Found VCE firmware/feedback version 50.0.1 / 17! [ 12.512158] [drm] GART: num cpu pages 524288, num gpu pages 524288 [ 12.515005] [drm] probing gen 2 caps for device 177d:a100 = 735c83/e [ 12.515008] [drm] PCIE gen 3 link speeds already enabled [ 12.537178] [drm] PCIE GART of 2048M enabled (table at 0x001D6000). [ 12.537338] radeon 0005:90:00.0: WB enabled [ 12.537342] radeon 0005:90:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x8007d78e0c00 [ 12.537345] radeon 0005:90:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x8007d78e0c04 [ 12.537348] radeon 0005:90:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x8007d78e0c08 [ 12.537351] radeon 0005:90:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x8007d78e0c0c [ 12.537354] radeon 0005:90:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x8007d78e0c10 [ 12.538388] radeon 0005:90:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0x13235a18 [ 12.639814] radeon 0005:90:00.0: failed VCE resume (-110). [ 12.639819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 12.639820] [drm] Driver supports precise vblank timestamp query. [ 12.639823] radeon 0005:90:00.0: radeon: MSI limited to 32-bit [ 12.639924] radeon 0005:90:00.0: Device has broken 64-bit MSI but arch tried to assign one above 4G [ 12.639980] [drm] radeon: irq initialized. [ 12.769447] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [ 12.783894] EXT4-fs (sda2): mounting ext2 file system using the ext4 subsystem [ 12.796215] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null) [ 12.79] [drm] ring test on 0 succeeded in 1 usecs [ 12.798893] [drm] ring test on 1 succeeded in 1 usecs [ 12.798898] [drm] ring test on 2 succeeded in 1 usecs [ 12.798906] [drm] ring test on 3 succeeded in 3 usecs [ 12.798912] [drm] ring test on 4 succeeded in 3 usecs [ 12.976107] [drm] ring test on 5 succeeded in 2 usecs [ 12.982846]
Bug#456491: closed by Yann Dirson [EMAIL PROTECTED] (0.14.1 in unstale already)
On 24/03/2008, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Mon, 24 Mar 2008, Debian Bug Tracking System wrote: Version: 0.14.1-1 This version has been uploaded already. Thanks. Do look at the stable git branch, though. Some important fixes are in there, and stgit upstream is notoriously bad at releasing in a timely manner. I just released 0.14.2 with those bug-fixes. Maybe you can add the new maintenance release into Debian. -- Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457826: stgit installation gives compile error
On 26/12/2007, Junichi Uekawa [EMAIL PROTECTED] wrote: Package: stgit Version: 0.14.1-3 I don't quite grok it but it gives an error when installing: Compiling /var/lib/python-support/python2.3/stgit/commands/common.py ... File /var/lib/python-support/python2.3/stgit/commands/common.py, line 513 @readonly_constant_property ^ SyntaxError: invalid syntax At least Python 2.4 is required for StGIT 0.14. Python 2.3 is not supported. -- Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298788: [Quilt-dev] [peterc@gelato.unsw.edu.au: Bug#298788: Desirable new feature: quilt merge]
Martin Quinson [EMAIL PROTECTED] wrote: also from the debian BTS. I dunno what to think about it. I never forked any patch, so I've no idea about merging them afterward ;) Assuming that you only try to merge forked patches, a diff3 merge could be performed between the common ancestor of all the files, the old patch and the newly forked one. The common ancestor is easy since you get it in .pc/patch/file, the local file is one of the descendants and 2nd descendant is generated by applying the forked patch to the ancestor. Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298788: [Quilt-dev] [peterc@gelato.unsw.edu.au: Bug#298788: Desirable new feature: quilt merge]
Catalin Marinas [EMAIL PROTECTED] wrote: Martin Quinson [EMAIL PROTECTED] wrote: also from the debian BTS. I dunno what to think about it. I never forked any patch, so I've no idea about merging them afterward ;) Assuming that you only try to merge forked patches, a diff3 merge could be performed between the common ancestor of all the files, the old patch and the newly forked one. The common ancestor is easy since you get it in .pc/patch/file, the local file is one of the descendants and 2nd descendant is generated by applying the forked patch to the ancestor. I just realised this won't work since diff3 will report conflicts for all the changes in both patches, even if they are the same. Maybe xxdiff is a bit smarter here but I'm not sure. The common ancestor should be the state of the tree when the fork happened but if both the old patch and the newly forked one are modified afterwards, this information is no longer preserved. Catalin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
