Bug#550379: acknowledged by developer (closing 550379)
reopen 550379 severity 550379 wishlist thanks On Sun, 18 Oct 2009 23:50:04 +0100 Ben Hutchings wrote: > On Sun, 2009-10-18 at 18:18 -0400, Michael S Gilbert wrote: > [...] > > in one sentence, my request is for the linux-2.6 and linux-kbuild-2.6 > > *source* packages to be merged (they are both in main, so there should > > be no social reason for this to be impossible). > > > > consequently, i fully support the continued existence of the kbuild > > binary packages (which would be built via the linux-2.6 source package > > instead of the separate linux-kbuild-2.6 source package). > > It is not for us to justify the way we package the kernel, but for you > to justify why we should change. We can make this a wishlist bug but we > have a long list of more important bugs. ok, thank you very much. that is all i was asking. when i find the time, i will see if i can implement the required changes. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550379: acknowledged by developer (closing 550379)
maybe there is also some confusion due to my use of the term "kbuild binary packages". i am referring to the linux-kbuild-$(uname -r) binary packages when i say that, not the plain old kbuild binary/source package. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550379: acknowledged by developer (closing 550379)
On Sun, 18 Oct 2009 21:56:57 +0200 maximilian attems wrote: > On Sun, Oct 18, 2009 at 03:40:02PM -0400, Michael S Gilbert wrote: > > > # explanation given by maintainer > > > close 550379 > > > > there is no explanation in the bug logs. the closest thing to an > > explanation is: > > > > This is not possible for other reasons. > > > > where the 'other reasons' are never explained. if someone can state > > these reasons, i would be content to give this up if they are justified. > > they are, please reread carefully > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550379#22 ok, i think we're caught in a continuing cycle of miscommunication and misinterpretation. for clarity, social contract item 4 states: 4. Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. i understand very well that you intend to serve the needs of your users, and i have no intention of impeding that. i have not intentionally made any statement contrary to that requirement in this thread and do not wish to do so. i, in fact, fully support the kbuild binary packages. i am part of the pkg-fglrx team, so i very much rely on kbuild's availablity. that package, of course, is non-free, and i have no problems with that fact. i too volunteer my time for the benefit of debian's users even on "non-free" stuff. the only way that i can understand the kernel team's perspective in message #22 is that you have misinterpreted my report as a request for kbuild to be done away with (maybe based on some non-free concept or something that i never stated). this was certainly not my intent, and perhaps i can clarify. in one sentence, my request is for the linux-2.6 and linux-kbuild-2.6 *source* packages to be merged (they are both in main, so there should be no social reason for this to be impossible). consequently, i fully support the continued existence of the kbuild binary packages (which would be built via the linux-2.6 source package instead of the separate linux-kbuild-2.6 source package). mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550379: acknowledged by developer (closing 550379)
> # explanation given by maintainer > close 550379 there is no explanation in the bug logs. the closest thing to an explanation is: This is not possible for other reasons. where the 'other reasons' are never explained. if someone can state these reasons, i would be content to give this up if they are justified. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-fglrx-devel] Auto-building out-of-tree kernel modules
On Sat, 17 Oct 2009 19:47:09 +0200 Patrick Matthäi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ben Hutchings schrieb: > >> Wasting time and bandwidth (fetching linux-headers etc)? Great... > > > > Building obscure modules for every kernel flavour on Debian's own > > auto-builders is also a waste, especially when just one broken module > > breaks the whole conglomeration package. > > It is a big difference if our auto-builders build them e.g. 12 times for > every architecture or if they have to be built on every end-consumer PC, > which are e.g. one million pcs. All those senseless lost of energy and > performance.. it takes about 3 seconds to build the fglrx module (on a modern machine), so i don't see this as too much of a problem. to put things in perspective, it actually takes longer for apt to read its package lists than to build the fglrx module, which is done a lot more often (i.e. every time the user invokes "apt-get update") than building the module. > It is also not a good idea to switch to dkms, now where nothing is > decided or it may end like with ia32-apt-get with many wasted developer > ressources. it may take some effort and learning on our part, but this is very doable. as long as dkms isn't going away, then the transition will not be a wasted effort. 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 Sat, 10 Oct 2009 03:03:06 +0200 Bastian Blank wrote: > On Fri, Oct 09, 2009 at 05:49:13PM -0400, Michael Gilbert wrote: > > > 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 work for the > > >> security team and increases the risk of errors, omissions, and mistakes. > > > No, it does not. It is a different source package and both are derived > > > from the same upstream code. > > two different source packages with portions being the same code are > > considered a case of an embedded code copy; which is generally > > considered bad practice from a security perspective. > > Well, please start with every source using autoconf then. autoconf > embeds copies of a large amount of source code snippets in the targets. > This have about the same practical relevance and use then the code we > are talking about. automatically generated code (a la autoconf) is not a concern for the security team. however, the kbuild code copy is not computer generated; it consists of human-created perl, c, and shell scripts. > > >> less significant, but also important, is that since the kbuild package > > >> is separated from the linux package, the kbuild packages always lag by > > >> weeks or months after a new kernel release; making it impossible to > > >> build modules for that new kernel. > > >> the recommended course of action is to update the linux-2.6 source > > >> package to also build the kbuild binaries. thanks. > > > This is not possible for other reasons. > > what are these reasons, and why do they seem so insurmountable? > > They are backed by §4 Social Contract. i don't see the connection between the social contract and your requirement to keep the kbuild source package separate from the kernel source package. after all, both packages are in main, so from a social perspective, there is nothing preventing them from being merged. > To be exact, it is part of the cross-compile support in the > linux packages. And yes, this is heavily used. ok, i already know the purpose of the kbuild package, and i already had the feeling that it was indeed used quite a bit. i had no intention of calling either of these facts into question. i don't see how these statements relevant to the discussion. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: rootkit not found by rkhunter
On Sun, 4 Oct 2009 12:10:04 -0400 Thomas Krichel wrote: > Michael S Gilbert writes > > > 'apt-get update && apt-get upgrade' followed by a reboot into the new > > kernel should bring you up to date. > > Since I just download the kernel last week I did not really > believe your advice but I have rebooted and the problem appears > gone! right, kernel updates do not apply until after reboot. the latest kernel images no longer warn about this, which has lead to an increased number of users opting not to reboot after upgrade (at least from the volume of similar resolutions to postings on this list recently). kernel team, would it be possible to get this warning reintroduced or added to the notification daemon? we want to keep users informed about the actions they need to take to stay secure, right? mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529318: linux-2.6: CVE-2007-6514 smbfs information disclosure vulnerability
On Thu, 13 Aug 2009 23:51:40 +0200 Moritz Muehlenhoff wrote: > On Mon, May 18, 2009 at 12:06:58PM -0400, Michael S. Gilbert wrote: > > Package: linux-2.6 > > Severity: important > > Tags: security > > > > Hi, > > > > The following CVE (Common Vulnerabilities & Exposures) id was > > published for linux-2.6. > > > > CVE-2007-6514[0]: > > | Apache HTTP Server, when running on Linux with a document root on a > > | Windows share mounted using smbfs, allows remote attackers to obtain > > | unprocessed content such as source files for .php programs via a > > | trailing "\" (backslash), which is not handled by the intended AddType > > | directive. > > > > If you fix the vulnerability please also make sure to include the > > CVE id in your changelog entry. > > Have you been able to test this against recent kernels such as 2.6.30? here is my assessment of this issue: the attack vector for this one is so obscure: the worst that can happen is disclosure of scripts hosted on an apache server serving those scripts, and only if those scripts are mounted from a windows share via smbfs. i'd almost be inclined to say no-dsa for this one (or issue a dsa that says don't host your web scripts on a windows share when using apache if you are concerned about the confidentiality of those scripts). it's hardly worth worrying about. i have not done any tests to determine affected versions, but it should be fairly straightforward to do so. see [0]. also, see redhat bug on this [1]. they have a patch for rhel 2.1, but i wasn't able to search it down. mike [0] http://www.securityfocus.com/archive/1/archive/1/485316/100/0/threaded [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-6514 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537409: info
while this bug is still open, would it make sense to disable the gcc option/optimization/bug/flaw that allows this vulnerability to exist? the "-fno-delete-null-pointer-checks" flag will completely disable this option kernel-wide [1]. obviously there is a tradeoff here. the null pointer optimization does make the kernel run a bit faster (and maybe that should be quantified to determine the impact), but on the other hand it opens up a slew of vulnerabilities. i think erring on the side of caution/security is the way to go. anyway, just a thought. mike [1] http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532376: this is CVE-2009-1389
this is CVE-2009-1389. patches available[1]. [1] http://git.kernel.org/linus/fdd7b4c3302c93f6833e338903ea77245eb510b4 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532722: linux-2.6: CVE-2009-1914 local dos in /proc/iomem on sparc
Package: linux-2.6 Version: FILLINAFFECTEDVERSION Severity: important Tags: security , patch Hi, the following CVE (Common Vulnerabilities & Exposures) id was published for linux-2.6. CVE-2009-1914[0]: | The pci_register_iommu_region function in | arch/sparc/kernel/pci_common.c in the Linux kernel before 2.6.29 on | the sparc64 platform allows local users to cause a denial of service | (system crash) by reading the /proc/iomem file, related to | uninitialized pointers and the request_resource function. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. Patches available [1]. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1914 http://security-tracker.debian.net/tracker/CVE-2009-1914 [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=192d7a4667c6d11d1a174ec4cad9a3c5d5f9043c -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532721: linux-2.6: CVE-2009-1385 dos in e1000 driver
Package: linux-2.6 Severity: important Version: 2.6.18.dfsg.1-24 (and newer) Tags: security , patch Hi, the following CVE (Common Vulnerabilities & Exposures) id was published for linux-2.6. CVE-2009-1385[0]: | Integer underflow in the e1000_clean_rx_irq function in | drivers/net/e1000/e1000_main.c in the e1000 driver in the Linux kernel | before 2.6.30-rc8, the e1000e driver in the Linux kernel, and Intel | Wired Ethernet (aka e1000) before 7.5.5 allows remote attackers to | cause a denial of service (panic) via a crafted frame size. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. Patches available [1]. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1385 http://security-tracker.debian.net/tracker/CVE-2009-1385 [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ea30e11970a96cfe5e32c03a29332554573b4a10 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529342: linux-2.6: ipv6 potential denial-of-service
Package: linux-2.6 Version: 2.6.26 Severity: important Tags: security patch Hi, The following CVE (Common Vulnerabilities & Exposures) id was published for linux-2.6. CVE-2009-1360[0]: | The __inet6_check_established function in net/ipv6/inet6_hashtables.c | in the Linux kernel before 2.6.29, when Network Namespace Support (aka | NET_NS) is enabled, allows remote attackers to cause a denial of | service (NULL pointer dereference and system crash) via vectors | involving IPv6 packets. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. Note that the kernel changelog says that this vulnerability was introduced in 2.6.27; however, I've checked and found that the 2.6.26 code is identical to vulnerable 2.6.27 code. Hence, it is my assessment that 2.6.26 is affected as well. Note also that etch-and-a-half (2.6.24) is likely affected as well, but I have not checked this. Since this is just a denial-of-service, it is of low severity/urgency. Patches are available [1] and more info [2]. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1360 http://security-tracker.debian.net/tracker/CVE-2009-1360 [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3f53a38131a4e7a053c0aa060aba0411242fb6b9;hp=0c9a3aaaf30e1d1994de58c554ef97a719e20892 [2] http://xorl.wordpress.com/2009/04/21/linux-kernel-net_ns-ipv6-null-pointer-dereference/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529326: linux-2.6: CVE-2009-0787 information disclosure in ecryptfs
On Mon, 18 May 2009 11:52:04 -0600, dann frazier wrote: > On Mon, May 18, 2009 at 01:28:56PM -0400, Michael S. Gilbert wrote: > > Package: linux-2.6 > > Version: 2.6.26-15lenny2 > > Severity: important > > Tags: security > > > > Hi, > > > > The following CVE (Common Vulnerabilities & Exposures) id was > > published for linux-2.6. > > > > CVE-2009-0787[0]: > > | The ecryptfs_write_metadata_to_contents function in the eCryptfs > > | functionality in the Linux kernel 2.6.28 before 2.6.28.9 uses an > > | incorrect size when writing kernel memory to an eCryptfs file header, > > | which triggers an out-of-bounds read and allows local users to obtain > > | portions of kernel memory. > > > > If you fix the vulnerability please also make sure to include the > > CVE id in your changelog entry. > > > > For further information see: > > > > [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0787 > > http://security-tracker.debian.net/tracker/CVE-2009-0787 > > This issue supposedly only affected 2.6.28 - do you have information > to the contrary? yes, i have studied the code/patches for this issue. the 2.6.26 ecryptfs kernel code is identical to that of the affected 2.6.28 code. hence, it is my assessment that 2.6.26 is vulnerable. i anticipate that this also affects etch-and-a-half (2.6.24) as well, but i have not checked yet. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529326: patches
tag 529326 patch thank you note that this affects the lenny and squeeze versions of the kernel (2.6.26). even though the kernel changelog says that this problem only affects 2.6.28, it actually affects any version before 2.6.28.9 that has ecryptfs. patches are available here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8faece5f906725c10e7a1f6caf84452abadbdc7b http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=76a67ec6fb79ff3570dcb5342142c16098299911 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529326: linux-2.6: CVE-2009-0787 information disclosure in ecryptfs
Package: linux-2.6 Version: 2.6.26-15lenny2 Severity: important Tags: security Hi, The following CVE (Common Vulnerabilities & Exposures) id was published for linux-2.6. CVE-2009-0787[0]: | The ecryptfs_write_metadata_to_contents function in the eCryptfs | functionality in the Linux kernel 2.6.28 before 2.6.28.9 uses an | incorrect size when writing kernel memory to an eCryptfs file header, | which triggers an out-of-bounds read and allows local users to obtain | portions of kernel memory. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0787 http://security-tracker.debian.net/tracker/CVE-2009-0787 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529318: linux-2.6: CVE-2007-6514 smbfs information disclosure vulnerability
Package: linux-2.6 Severity: important Tags: security Hi, The following CVE (Common Vulnerabilities & Exposures) id was published for linux-2.6. CVE-2007-6514[0]: | Apache HTTP Server, when running on Linux with a document root on a | Windows share mounted using smbfs, allows remote attackers to obtain | unprocessed content such as source files for .php programs via a | trailing "\" (backslash), which is not handled by the intended AddType | directive. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6514 http://security-tracker.debian.net/tracker/CVE-2007-6514 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
On Thu, 16 Apr 2009 23:50:54 -0600 dann frazier wrote: > > > The support for dynamically loadable kernel modules in Linux can be > > > abuses similarly. Does that make it a "grave security issue"? > > > > probably...at least until someone comes up with a secure way to do it. > > Oh, come on. > > grave > makes the package in question unusable or mostly so, or causes > data loss, or introduces a security hole allowing access to the > accounts of users who use the package. > > Is the kernel really unusable/insecure because a root user can do > something bad? Wouldn't that give every package a grave bug by > definition? maybe the definition needs to be rethought in the context of rootkits. i think the kernel has to be considered more insecure under the influence of a rootkit (since rootkits make it much harder to detect that your system has be compromized). > I certainly don't consider this issue invalid - and in fact, we have > taken action to resolve it for the next release - but please don't > blow it out of proportion. i'm not trying to blow it out of proportion; just trying to make sure that the issue gets the consideration that it deserves. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
btw, redhat-based distros are thought to be invulnerable to these attacks due their incorporation of execshield (in particular, due to address space randomization). perhaps it's high time that debian consider doing the same? i know that execshield is not in the vanilla kernel, but when it comes to security, you have to admit that a lot is missing from the vanilla kernel. the default debian kernel should be hardened. period. you need to protect your users. it's disappointing when researchers can point to vista and say hey, they put an end to a lot of attacks in 2007 (via their address space randomization implementation); while in 2009 the same statement still can't be made for debian-derived distros. why is the linux kernel two years behind the state-of-the-art when it comes to security? why is redhat doing the right thing while debian does nothing? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
reopen 524373 thanks On Thu, 16 Apr 2009 16:53:38 -0400 Noah Meyerhans wrote: > On Thu, Apr 16, 2009 at 04:21:10PM -0400, Michael S. Gilbert wrote: > > > > i think that any flaw that allows an attacker to elevate his pwnage from > > root to hidden should always be considered a grave security issue. > > Your argument sounds like the one used by RIAA, MPAA etc, based on the > DMCA's anti-circumvention clause, to keep things like open source dvd > players illegal. Just because something can be used for malicious > purposes, doesn't mean its existance is a bad thing. There are reasons > for /dev/mem to exist, and why you might want to manipulate kernel state > through it. Many of these do not involve rootkits. this is a strawman argument. i never said that /dev/mem needed to go away. my point was that it needed to be secured against these newly discovered attacks, and it sounds like CONFIG_STRICT_DEVMEM does this. > The support for dynamically loadable kernel modules in Linux can be > abuses similarly. Does that make it a "grave security issue"? probably...at least until someone comes up with a secure way to do it. > But as Dann pointed out, we'll have CONFIG_STRICT_DEVMEM in the future > to help minimize exposure. this is a very good thing, and i understand that it would cause a lot of hassle to backport this kind of change to stable since it could potentially break compatibility. however, that doesn't mean that the issue shouldn't be tracked. and it certainly doesn't mean that the bug should be closed. i thought that one of debian's tenants was "we will not hide problems." > If you want to continue this discussion, I propose to do it outside the > BTS. why? isn't the bts a perfectly good place for discussion? mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
On Thu, 16 Apr 2009 12:43:07 -0400, Noah Meyerhans wrote: > On Thu, Apr 16, 2009 at 11:55:05AM -0400, Michael S. Gilbert wrote: > > as seen in recent articles and discussions, the linux kernel is > > currently vulnerable to rootkit attacks via the /dev/mem device. one > > article [1] mentions that there is an existing patch for the problem, > > but does not link to it. perhaps this fix can be found in the kernel > > mailing lists. > > There's no vulnerability there. /dev/mem is only writable by root. > > The research (if there's really any research involved) just shows how > you could hide files or processes by manipulating /dev/mem. That's been > known for ages. That's why you don't let your users write to /dev/mem. > If the attacker has root, who cares what means they use to hide their > precese, you've already lost. i believe that the "if they've got root, you've already lost" consensus is a logical fallacy. an aspect of security is being able to detect when you have been compromised. hence, it is a lot worse when the attacker is able to mask their presence. at least when they only have root they leave tracks and you can detect files, configs, and utilities that differ from the norm or are out of place. i think that any flaw that allows an attacker to elevate his pwnage from root to hidden should always be considered a grave security issue. best regards, mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524373: linux-2.6: /dev/mem rootkit vulnerability
package: linux-2.6 severity: grave tags: security as seen in recent articles and discussions, the linux kernel is currently vulnerable to rootkit attacks via the /dev/mem device. one article [1] mentions that there is an existing patch for the problem, but does not link to it. perhaps this fix can be found in the kernel mailing lists. [1] http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=216500687 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521482: linux-2.6: adopt hardening patches (execshield and grsecurity) into default kernel packages for squeeze
package: linux-2.6 severity: wishlist tags: security there are now several security hardening kernel patches available in the debian archive (e.g. execshield and grsecurity). it would be great if these patches were incorporated into the default kernel packages. this would go a long way toward reducing the impact of security threats to the majority of end users. most users will never consider applying those patches or building/using a non-vanilla debian kernel. thank you for your consideration. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#447549: closed by Bastian Blank (Bug#447549: fixed in linux-2.6 2.6.29-1)
Thanks to the debian and upstream kernel teams for fixing this longstanding bug! It's good to know that the process sometimes may take quite a bit of time, but it does work! Regards, Mike On Tue, 24 Mar 2009 21:12:05 +, Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > which was filed against the linux-2.6 package: > > #447549: linux-2.6: orinoco.c printk messages flood terminal > > It has been closed by Bastian Blank . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Bastian Blank > by > replying to this email. > > > -- > 447549: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447549 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#447549: patch available
tag 447549 patch thank you one of the upstream developers created a patch for this problem [1]. i assume that since this is so straightforward it will likely be applied to the vanilla kernel without too much hesitation (maybe in the 2.6.30 timeframe). i will watch the upstream list for a commit message. [1] http://marc.info/?l=linux-wireless&m=123233887415461&w=2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
