* Joey Hess:
- Debian's userland has *always* supported at least the previous major
kernel version, and most often the previous two, or sometimes I
think, three major kernel versions.
This isn't a real argument, IMHO, because upstream no longer releases
major kernel versions.
OTOH,
Package: linux-2.6
Version: 2.6.18-7
Severity: wishlist
Please apply the attached patch to add support for the 9650SE
controllers. All changes should be relatively low-risk.
(The patch is part of 2.6.19. It applies to 2.6.17 and later as-is.)
commit 4039c30ef5d9189ff8dc72aaf610d1c933877e20
Here's something that could be related (APT seems to call msync as
well):
http://article.gmane.org/gmane.linux.kernel/473710
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Has CVE-2006-5648 been addressed for the current linux-2.6 version?
Here's what I've found out about this bug so far:
NOTE: Some new futex-related system calls need arch-specific support
NOTE: routines, or they can lead to unkillable userspace processes.
NOTE: The following git commits add
* Bastian Blank:
Not possible without another large round of testing. Our infrastracture
currently expects that the upstream part of the version remains
the same through the whole cycle. This information is for example used
to find all patches.
Uhm, why can't you do a simple full upload just
* dann frazier:
Here's the current list of stuff I'd been tracking for an etch update
- this doesn't mean they were approved by the SRM team, just that they
are on my list of things to review:
http://bugs.debian.org/cgi-bin/[EMAIL
PROTECTED];which=tagdata=dkt-etch-update
Any chance to
* Brian Almeida:
I've been unable to find an official debian kernel which has
Xen supporter after 2.6.18-5 (released with etch). While I realize
there were changes in later kernels that complicated the patches,
Ubuntu has had Xen support for 2.6.22 for nearly 3 months (see
* maximilian attems:
On Fri, Jan 25, 2008 at 12:12:57AM -0800, Rich Wales wrote:
Thus, /dev/sda may not necessarily be the same as the boot drive.
If, for instance, I have two SATA drives plugged into physically
labelled ports 1 and 2, the computer will try to boot off the drive
plugged
* Vitaliy Okulov:
Yep, im sure.
Ah, okay, but I think this is not CVE-2008-0009 or CVE-2008-0010.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Vitaliy Okulov:
Oh, just reread http://marc.info/?l=linux-kernelm=120262352612128w=2
Thereis no bugfix.
Yes, it appears to be a different bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Bastian Blank:
diff --git a/fs/splice.c b/fs/splice.c
index 684bca3..2d7e598 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1122,6 +1122,11 @@ static int get_iovec_page_array(const struct iovec
__user *iov,
size_t len;
int i;
+ if
severity 420875 grave
thanks
According to debsecan and current CVEs is Debian vulnerable to
CVE-2007-1734. Because this is remote exploitable i set the priority of
this bug report to critical.
Huh? CVE-2007-1734 is only locally exploitable according to the
published sources.
The text you
On Mon, Jul 23, 2007 at 05:41:47PM +0200, Bastian Blank wrote:
I nor any of the other debian users have seen this. If you want to get
it fixed in this kernel, identify the upstream commit which fixed it.
OK. Can you point me to some good howtos, tools or websites where i can
get an overview
* Nathanael Nerode:
The most recent linux-source-2.6.22 contains the following files:
drivers/media/video/dabfirmware.h
Probably okay, could be a frequency table or some kind of bitmap. Who
knows.
drivers/net/drgs_firmware.c
Doesn't exist upstream. Huh?
drivers/usb/misc/emi26_fw.h
* Markus Broeker:
Tags: security
X-Debbugs-CC: [EMAIL PROTECTED]
Why do you think this is a security bug?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Michael Loftis:
The 2.6.18-6 kernel has a buggy 3w- driver. Causes data
corruption on (at least) EM64T w/ 4+GB of RAM. I'm also pretty sure
it's the cause of corruption on EM64T systems in 32-bit mode even w/o
4+GB of RAM. Specifically it affects 7xxx and 8xxx series cards.
* dann frazier:
But that doesn't make them security issues. Don't get me wrong, I'd be
all for a more fluid update process for non-security/critical issues,
but it doesn't exist at the moment. The security team controls what
goes out as a security update, and we're not going to get the
* maks attems:
On Sat, 04 Dec 2004, Matthew Wilcox wrote:
On Sat, Dec 04, 2004 at 01:01:33PM -0500, Kyle McMartin wrote:
* ACENIC firwmare, driver disabled:
. drivers/net/acenic_firmware.h
So there's a good reason why you're unable to use these cards.
ITYM good reason to switch to
The changelog entry for CAN-2005-0449 (in kernel-source-2.6.8) reads:
* ipv4-fragment-queues-1.dpatch, ipv4-fragment-queues-2.dpatch,
ipv4-fragment-queues-3.dpatch, ipv4-fragment-queues-4.dpatch:
fix potential information leak by making fragment queues private.
CAN-2005-0449 (Joshua
It seems that the i386 and amd64 autobuilders do no longer upload
their builds to unstable. What's going wrong? (2.6.16-14 hasn't been
built on amd64 yet, but -13 has been, and it's not in unstable,
either.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
* Bastian Blank:
On Sat, May 27, 2006 at 10:20:06AM +0200, Florian Weimer wrote:
It seems that the i386 and amd64 autobuilders do no longer upload
their builds to unstable. What's going wrong? (2.6.16-14 hasn't been
built on amd64 yet, but -13 has been, and it's not in unstable,
either
* Goswin von Brederlow:
I would suggest keeping the name amd64-generic. It is easier for users
to see that -generic fits all than -k8.
It's also easier to reintroduce split packages if necessary.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
* Frederik Schueler:
-generic is odd and too long. I am considering to change the naming
scheme completely, and call the flavours 2.6.x-y-amd64 and
2.6.x-y-em64t respectively.
Newer GCCs produce AMD64 code which is supposed to be closed to
optimal to what GCC can produce on EM64T. Does it
* Francesco Pietra:
What about k8-smp?
Do we still need non-SMP kernels in the age of hyperthreading,
multi-core CPUs, and preemption?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Robert Millan:
The linux-2.6 packages in unstable are not affected (since they
don't include a.out support).
That's not correct, the vulnerability is present even if a.out support
is disabled. It's only one published exploit that requires a.out
support.
--
To UNSUBSCRIBE, email to [EMAIL
* Bastian Blank:
Unchecked patch attached. It disallows changes from and to PROT_NONE.
Huh? Doesn't this break the user-space ABI?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Andres Salomon:
How can you tell? The mitre description is absolutely useless. I
fucking hate this stupid vendor-sec/mitre non-disclosure policy,
In most cases, MITRE does not have access to pre-disclosure
information. They just hand out unique names, and update the database
based on
* dann frazier:
Horms: I realize you might be somewhat out of the loop as to how we're
abusing your directory tree; I'll catch you on IRC when you're back to
explain in detail.
Could you write a short statement to the mailing lists, please?
For example, I'd like to get a list of the 2.6.12.6
Is the issue described below already on your radar screen? I couldn't
find it in the relevant files. AFAICT, no CVE name has been assigned.
commit 4717ecd49ce5c556d38e8c7b6fdc9fac5d35c00e
Author: Patrick McHardy [EMAIL PROTECTED]
Date: Mon Jul 18 06:52:50 2005 +0200
[PATCH] Fix
On Tue, Oct 25, 2005 at 05:35:19PM +0200, Florian Weimer wrote:
Is the issue described below already on your radar screen? I couldn't
find it in the relevant files. AFAICT, no CVE name has been assigned.
Its the first I've seen of it, but that doesn't mean much.
Which GIT tree
* Christoph Siess:
Correct my if I got something wrong, but according to my
understanding this shouldn't be possible with version
2.6.26-17lenny2.
Correct.
Linux version 2.6.26-2-686 (Debian 2.6.26-17lenny1) (da...@debian.org) (gcc
version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1
* maximilian attems:
sorry i might miss you point:
what do you expect md to do?
I was surprised that the array was degraded. Note how the write
operation failed on both devices, so the behavior is rather
inconsistent.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with
I wonder if it makes sense to set vm.mmap_min_addr to 4096 (instead of
0) for lenny. It seems to me that unstable already made this switch,
and given the apparently neverending sequence of kernel NULL
dereferences, this might be quite helpful.
--
To UNSUBSCRIBE, email to
* Ben Hutchings:
Symptoms are corrupted fonts (instead of characters, bounding boxes
are shown), missing characters, a general slowdown of some graphics
operations (there is a very noticeable delay when maximizing
Iceweasel), and, worst of all, relatively frequent complete lock-ups
during
* Ben Hutchings:
Yes. If I understood you correctly, your system works better with KMS
initially enabled and firmware missing, than with KMS disabled and
firmware missing.
Okay, I filed bug 697229 for this.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject
* Ben Hutchings:
However, there is now a blog post from Microsoft that supports what
Matthew Garrett has been saying for a while - they may revoke the
signature on a boot loader if signature verification is not extended to
the kernel, including any mechanism to chain-load another kernel:
* Ben Hutchings:
The Terms Conditions of existing EV code-signing CAs do not permit a
code-signing end-entity certificate to be used for signing another
certificate, so we'd directly have to embed the end-entity certificate
used to sign GRUB and the kernel into the shim—or we'd have to ship
* Colin Watson:
On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote:
Furthermore, we need to store the keys for all EV certificates (both
the certificate used for submission, and the certificate embedded in
the shim) in devices that meet at least FIPS 140 Level 2. Such
devices
* Ben Hutchings:
> To ensure the integrity of the kernel, we should support a securelevel
> where all modules must be signed by a trusted key and all APIs
> allowing arbitrary memory writes are disabled.
What is a trusted key? I'm not convinced we can align this with
Debian's principles.
> To
* Christoph Berg:
> More details:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483
Why do you consider this a security issue? Do you consider it an
availability issue?
I'm a bit confused why this shows up as a userspace allocation
failure. glibc should switch to mmap (creating
found 907585 20180518-1~bpo9+1
thanks
firmware-cavium_20180518-1~bpo9+1_all.deb is still in the package pool
and contains the offending binary.
* Paul Gevers:
> * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)
glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.
> * Concern
42 matches
Mail list logo
