Re: retiring from security team
Hi Dann, Op vrijdag 26 september 2014 22:02:35 schreef dann frazier: > hey, > I've been unable to find time to work on kernel security updates for > some time now and - since I don't see that changing - it is time I > officially retire from the team. DSA, please remove me from the > appropriate groups. > > Thanks to Martin & Moritz for helping me get started with my first > DSAs in '05, '06 (woody was painful[1]), to Ben, Moritz and Salvatore > for keeping the kernel DSAs coming since I started slacking, and to > the rest of you for continuing to help keep my computers secure :) > > [1] https://lists.debian.org/debian-security-announce/2006/msg00168.html Thanks a lot for your work. It has been critical to keeping Debian secure. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#705618: rcu_bh detected stall on CPU
Hi, We're seeing on different VM's running Wheezy 7.2 with linux 3.2.51-1 the same message: INFO: rcu_bh detected stall on CPU 1 (t=0 jiffies) According to http://lwn.net/Articles/520158/ there are two likely commits that fixed this; a10d206e wheezy already has, but c96ea7cf has not yet been backported. Would it make sense to do that? -- Thijs Kinkhorst – LIS Unix Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl signature.asc Description: This is a digitally signed message part.
Bug#597658: possible to enable aesni-intel in squeeze?
Hi, > > the module was actually completely broken in 2.6.32 if > > CONFIG_CRYPTO_FIPS=y (which it is in Debian packages). However, it > > also looks like this was fixed in 2.6.32.19, which is incorporated in > > the source for the current package. > fyi, 2.6.32-12 & 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot > successfully w/ the aesni_intel module on my Lenovo T410. Reading the bug log I'm tempted to conclude that this problem has been dealt with, at least since 2.6.32.19. The module has also since long been enabled in unstable. Would it therefore be feasible to re-enable it in an upcoming Squeeze point update? thanks, Thijs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/11783a8991fe67ee5fb1e9d0c7553cf2.squir...@wm.kinkhorst.nl
Bug#532376: r8169: network buffer overflow
On tiisdei 9 Juny 2009, Ben Hutchings wrote: > Package: linux-2.6 > Version: 2.6.29-5 > Severity: critical > Tags: security patch > > Some or all NICs supported by r8169 seem to ignore the buffer sizes in > RX descriptors, and will write up to the global maximum frame size. > This means a remote attacker can overflow RX buffers, probably > allowing for code injection. This should be fixed by the patch posted > in: > > http://article.gmane.org/gmane.linux.network/130114 This is CVE-2009-1389. The severity of this issue is still debated. Thijs signature.asc Description: This is a digitally signed message part.
Bug#420241: not fixed in 2.6.20
reassign 420241 quota found 3.14-7 closed 3.15-4 thanks > Edquota segfaults, quota command results: > > # quota -u 1500 > quota: error while getting quota from /dev/sda7 for #1500 (id 1500): > Success Bastian Blank wrote: > Fixed in 2.6.20, not fixed in 2.6.18. I'm afraid this is not right. I got the exact same problem as detailed above both with the standard etch kernel, as with the 2.6.21 kernel from bpo. So it's not fixed by using a newer kernel. But rather, when taking the unstable package of quota (3.15-4), building it for and installing it on my etch system (with the kernel reverted to 2.6.18-5), the problem disappears. I'm therefore reassigning this bug to the quota package, for reference for those also experiencing the bug in stable, but marked as fixed in the latest sid version. Let me know if there's a problem with that. Thijs
