Both /dev/random and /dev/urandom seem to work fine. dd if=/dev/random bs=4 count=1 2>/dev/null | hd 00000000 80 bd 4b 28 |..K(|
dd if=/dev/urandom bs=4 count=1 2>/dev/null | hd 00000000 8d 62 6f 3b |.bo;| On Thu, Nov 27, 2014 at 8:07 PM, NIIBE Yutaka <gni...@fsij.org> wrote: > On 11/28/2014 10:51 AM, Pandu Rao wrote: >> Package: gnupg >> Version: 1.4.18-4 >> Severity: normal > [...] >> *** buffer overflow detected ***: gpg terminated >> ======= Backtrace: ========= >> /lib/x86_64-linux-gnu/libc.so.6(+0x7303f)[0x7f581fd9d03f] >> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f581fe20147] >> /lib/x86_64-linux-gnu/libc.so.6(+0xf4360)[0x7f581fe1e360] >> /lib/x86_64-linux-gnu/libc.so.6(+0xf60b7)[0x7f581fe200b7] >> gpg[0x4916c8] > > Disassembling /usr/bin/gpg, it seems for me that it's __fdelt_chk > which caused this "buffer overflow": > > 4916c3: e8 e8 21 f7 ff callq 4038b0 <__fdelt_chk@plt> > 4916c8: 8b 7c 24 28 mov 0x28(%rsp),%edi > > One possibility is gnupg-1.4.x/cipher/rndlinux.c:rndlinux_gather_random. > > When /dev/random (or /dev/urandom), is not accessible, for some > reason, I think that this buffer overflow is possible when FD_SET > (at line 125). > > This is just a my theory. It's pretty unusual you don't have > /dev/random (or /dev/urandom), so, I must be wrong. > > But, just in case, could you please check your environment if /dev/random > is normal or not? > -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org