Bug#892517: linux: swiotlb coherent allocation failed

control: found -1 4.16.5-1 control: reopen -1 This is back for me as well. Best wishes, Mike

Bug#892517: linux: swiotlb coherent allocation failed

On Tue, Mar 20, 2018 at 6:15 AM, Salvatore Bonaccorso wrote: > Can you confirm that before we would proceed to mark it as fixed with > 4.15.11-1? I have not seen it since updating, so I think it can be considered fixed. Best wishes, Mike

Bug#892517: linux: swiotlb coherent allocation failed

package: src:linux version: 4.15.4-1 severity: minor forwarded: https://lkml.org/lkml/2017/12/18/1259 This is a message that shows up a lot in dmesg starting with linux 4.15. See LKML discussion and Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749202 Best wishes, Mike

re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC

> Julien Tinnes from google says that next releases of chromium will > drops support for kernels without TSYNC So, first of all, this has never been Google's track record when it comes to missing sandbox features. They happily use fall backs whenever you're missing support for any of those. See

Bug#772508: linux: mitigate offset2lib ASLR issue

package: src:linux severity: important version: 3.16.7-1 control: tag -1 security control: forwarded -1 https://lkml.org/lkml/2014/12/5/482 A fix is currently being developed for an an ASLR bypass issue (see link). Please consider applying and enabling it by default for jessie kernels once a fina

Bug#704987: system freezes after hibernate/suspend

control: severity -1 important Reducing severity since this doesn't meet the kernel team's requirements for a grave or higher. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Arch

Bug#703468: linux-image-3.2.0-4-amd64 fails to boot on apple iMac

> The following string is still recognizable: > i915_gem_init_ppgtt+0x93/0x16c [i915] This is going to take some work on your end to get fixed. 3.2.39-1 included backported patches from aspects of the i915 driver. To help, you could do some testing by unapplying those patches and rebuilding the

Bug#700884: linux: please use a three-number version for experimental kernel packages

> That's using a kernel three releases newer than the userland. We > generally like backward compatibility, but I don't it's tenable to go > that far. I find this loss of compatibility unfortunate. I think there is value in continuing to support chroots of old releases. > Does the uname26 progr

Bug#700884: linux: please use a three-number version for experimental kernel packages

package: linux severity: important control: affects -1 src:debootstrap uname presents a two-number version in the experimental kernel packages, e.g. $ dpkg -l | grep linux-image ii linux-image-3.7-trunk-amd643.7.3-1~experimental.1 $ uname -r 3.7-trunk-amd64 This makes it imp

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sun, 20 Feb 2011 08:24:32 +0100 Lucas Nussbaum wrote: > On 19/02/11 at 17:40 -0500, Michael Gilbert wrote: > > On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote: > > > > Hypothesis 1: using an older kernel in testing results in fewer > > > > vulnerabil

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote: > > Hypothesis 1: using an older kernel in testing results in fewer > > vulnerabilities > > > > Criteria: fewer vulnerabilities in lenny than squeeze during squeeze > > testing cycle > > Evidence: lenny's kernel was vulnerable to 67% of

Re: [Secure-testing-team] [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 22:28:17 +0100 Bastian Blank wrote: > On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert wrote: > > Hypothesis 1: using an older kernel in testing results in fewer > > vulnerabilities > > > > Criteria: fewer vulnerabilities in lenny

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 20:30:47 + Ben Hutchings wrote: > On Sat, 2011-02-19 at 14:59 -0500, Michael Gilbert wrote: > > On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: > [...] > > > > Again, if the user is interested in such new developments, they will > > &

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 14:59:27 -0500 Michael Gilbert wrote: > On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: > > > On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote: > > > On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: > > > > > &

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: > On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote: > > On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: > > > > > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote: > [...] > > &

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote: > [...] > > Also, this solution isn't just about CUT stability. As I've been > > describing, it is about killing about 2 birds with one stone: >

Re: [cut-team] For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote: > On Fri, 18 Feb 2011, Michael Gilbert wrote: > > This will also help to provide a bit more stability for CUT [0]. Over > > a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream > > kernels will be r

Re: For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: > On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote: > > Michael Gilbert wrote: > > > Another issue was that a lot of vulnerabilities that were found in that > > > time frame were actually flaws in new kerne

Re: For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: > Even playing the numbers game with a bit more thoughtful analysis with > the LWN data, lenny looks a lot better. It can be seen that lenny > (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities > listed there,

Re: For discussion: security support strategy for the wheezy kernel

Hi Joey, Thank you so much for your very thoughtful reply. On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote: > Michael Gilbert wrote: > > Another issue was that a lot of vulnerabilities that were found in that > > time frame were actually flaws in new kernel code, so testing/un

Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel

On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote: > What does that buy us?  It means instead of dealing with bugs on an > ongoing basis, you get them all at the same time and get to bisect along > many kernel versions at once instead of just one.  It means problems > don't get reported (and fix

Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel

On Mon, Feb 7, 2011 at 5:08 PM, Michael Gilbert wrote: > What about introducing a new linux-2.6-stable kernel package as a > compromise?  That way users that want stability and security support > in testing continue to have that as an option.  Also, I will assume > responsibility as th

Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel

2011/2/7 Ben Hutchings wrote: > On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote: >> Michael Gilbert schrieb: >> > Hi, >> >> > So, my proposal in a nutshell is to only upload upstream 2.6.32 point >> > releases to wheezy/si

Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote: > Michael Gilbert schrieb: > > Hi, > > > So, my proposal in a nutshell is to only upload upstream 2.6.32 point > > releases to wheezy/sid for the next 12-18 months. At that time, > > reevaluate and de

For discussion: security support strategy for the wheezy kernel

Hi, Now that squeeze is released, I've started thinking about how to improve the quality of security support for testing. The biggest problem I saw during the squeeze development cycle was that kernel security update transitions were extremely slow due to unrelated RC bugs. This was bad since

Bug#597576: [Secure-testing-team] Bug#597576: linux-image-2.6.32-5-amd64: 2.6.32-23 still vulnerable to CVE-2010-3301

On Mon, 20 Sep 2010 18:51:16 -0400 Jon wrote: > > Package: linux-2.6 > Version: 2.6.32-23 > Justification: root security hole > Severity: critical > Tags: security > > > The changelog says the CVE-2010-3301 was fixed in this update: > * x86-64, compat (CVE-2010-3301): > - Retruncate rax a

Bug#564110: r8169: Fix for CVE-2009-1389 introduces denial of service issue

can we downgrade the severity of this issue since there is a fix included (even though it isn't ideal)? it's currently RC. best wishes, mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive

Bug#579175: linux-2.6: does not remove /lib/modules/modules.softdep on removal

package: linux-2.6 severity: minor version: 2.6.32-11 "apt-get purge linux-image-2.6.32-4-amd64" does not currently clean up the modules.softdep file in /lib/modules. minor issue; thanks for looking into it. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subje

Bug#569724: Please support /etc/kernel/header_postinst.d directory

here is some initial work on a patch for this issue. i'm not familiar enough with kernel packaging right now, and i've run into a problem. right now, the new headers postinst is placed into the debian/linux-headers-*-$arch directory at build time, which i thought would be sufficient to get it into

Bug#564114: [Secure-testing-team] e1000: Potential packet filtering bypass

On Fri, 08 Jan 2010 13:38:37 +, Ben Hutchings wrote: > On Thu, 2010-01-07 at 22:11 -0500, Michael Gilbert wrote: > > On Thu, 07 Jan 2010 19:27:02 + Ben Hutchings wrote: > > > > > Julien Cristau pointed out the thread > > > <http://thread.gmane.org/

Bug#564114: [Secure-testing-team] e1000: Potential packet filtering bypass

On Thu, 07 Jan 2010 19:27:02 + Ben Hutchings wrote: > Julien Cristau pointed out the thread > . It > appears that Red Hat allocated CVE-2009-4536 for this and CVE-2009-4538 > for a similar bug in e1000e. do you follow kernel-sec [

Bug#562975: linux-2.6: patch for CVE-2009-3939

> Actually, no Debian release contains a kernel version affected by > CVE-2009-3889. CVE-2009-3889 was fixed in upstream commit 66dca9b8 in linux 2.6.27, so debian's 2.6.24 and 2.6.26 are affected, but 2.6.18 and 2.6.32 are not. You can look at the dbg_lvl permissions, for example in the 2.6.32 ke

Bug#562975: linux-2.6: patch for CVE-2009-3939

package: linux-2.6 version: 2.6.32-3 severity: important tags: patch , security hi, attached is a patch for the megaraid poll_mode_io permissions issue. mike diff -ur a/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c b/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c --- a/linux-2.6-2

Bug#560831: linux-2.6: make linux-headers automatically install headers for all currently installed kernel images

package: linux-2.6 version: 2.6.32-1 severity: wishlist hi, a lot of module building issues could be solved if the linux-headers packages were to automagically install all of the corresponding headers for all of the currently installed kernel images (instead of just providing a virtual package to

Bug#550379: closed by Bastian Blank (Re: Bug#550379: linux-kbulid-2.6: embeds linux-2.6)

ropen 550379 thanks the preceding discussion has not resolved this issue satisfactorily. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#550379: closed by Bastian Blank (Re: Bug#550379: linux-kbulid-2.6: embeds linux-2.6)

> > On Fri, Oct 09, 2009 at 02:04:20PM -0400, Michael Gilbert wrote: >> the linux-kbuild-2.6 source package includes portions of code from the >> linux-2.6 source package (i.e. everything in ./kbuild/*). this is bad >> in terms of security support because it causes more w

Bug#550379: linux-kbulid-2.6: embeds linux-2.6

package: linux-kbuild-2.6 version: 2.6.30-1 severity: important tags: security hi, the linux-kbuild-2.6 source package includes portions of code from the linux-2.6 source package (i.e. everything in ./kbuild/*). this is bad in terms of security support because it causes more work for the securit

Bug#521482: closed by maximilian attems (Re: Bug#521482: linux-2.6: adopt hardening patches (execshield and grsecurity) into default kernel packages for squeeze)

> get them upstream merged > see http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines but doesn't it make sense to be proactive about security? this isn't really a security "fix", but it a security improvement. i can't even fathom how to get this merged upstream since redhat has been wor

Bug#447549: linux-2.6: orinoco.c printk messages flood terminal

forwarded 447549 http://marc.info/?l=linux-wireless&m=123058933020818&w=2 thank you just forwarded this today. please follow progress upstream. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#447549: linux-2.6: orinoco.c printk messages flood terminal

> > would it > > be feasible to have level 6 as the default printk level in debian rather > > than 7? > hiding info, i'm sorry but that's not what people expect from debian, info is not being hidden -- it will still be fully available via dmesg. and if someone really wants/needs this level of ve

Bug#447549: linux-2.6: orinoco.c printk messages flood terminal

Package: linux-2.6 Version: 2.6.22-2 Severity: normal i am at a location where a nearby wireless router comes in and out of range, so i get a ton of "eth2: New link status: AP Out of Range (0004)" and "eth2: New link status: AP In Range (0005)" messages on the active terminal. this makes it dif

Bug#268583: hotplug failure with shpchp and pciehp

<[EMAIL PROTECTED]> wrote: > On Wed, Nov 02, 2005 at 08:45:41PM -0500, Michael Gilbert wrote: > > Package: linux-2.6 > > Followup-For: Bug #268583 > > > > > Could any of the affected parties verify this is still a problem > > > with 2.6.12-4. I

Bug#268583: hotplug failure with shpchp and pciehp

Package: linux-2.6 Followup-For: Bug #268583 > Could any of the affected parties verify this is still a problem > with 2.6.12-4. I expect it is, but it would be good to verify. i couldn't find a linux-image-2.6.12-4 package anwhere, but i can verify that the kernel log contains this error: Nov

Bug#268583: hotplug failure with shpchp and pciehp

Package: kernel Followup-For: Bug #268583 i too encounter this system on my Dell Inspiron 8200 laptop. i reported the problem to the hotplug maintainer, which was abrubtly closed without sufficient explaination (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334172). an lspci of my system i

Re: Adding linux-image- dependency on linux-headers-?

> Now, those wanting to compile third party drivers like the nvidia ones, should > take the nvidia package (or whatever it is called) and build it following to > instructions, or even better, the new policy should call for pre-compilation > for all official flavours of those modules, like it is al

Adding linux-image- dependency on linux-headers-?

Hello all, I am curious as to the reasoning behind not including the kernel headers along with a kernel install?  The reason that I bring this up is that many (new/Joe) users end up unable to figure out why they can't compile certain modules (such as the nvidia driver, etc.)...until someone more k