Martin Schulze
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6 kernel
Moritz Muehlenhoff wrote:> Hi Horms / security team, > I found three more security related reports/patches on linux-kernel. > > Cheers, > Moritz > > From: David Howells <dhowells@redhat.com> > > Plug request_key_auth memleak. This can be triggered by unprivileged > users, so is local DoS. > > Signed-off-by: Chris Wright <chrisw@osdl.org> > Signed-Off-By: David Howells <dhowells@redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > --- > security/keys/request_key_auth.c | 1 + > 1 file changed, 1 insertion(+) > > --- linux-2.6.13.y.orig/security/keys/request_key_auth.c > +++ linux-2.6.13.y/security/keys/request_key_auth.c > @@ -96,6 +96,7 @@ static void request_key_auth_destroy(str > kenter("{%d}", key->serial); > > key_put(rka->target_key); > + kfree(rka); > > } /* end request_key_auth_destroy() */This is CAN-2005-3119 and... uh... not supposed to be public yet... Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] Three more security problems in the 2.6 kernel
Hi Horms / security team,
I found three more security related reports/patches on linux-kernel.
Cheers,
Moritz
From: David Howells <dhowells@redhat.com>
Plug request_key_auth memleak. This can be triggered by unprivileged
users, so is local DoS.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
security/keys/request_key_auth.c | 1 +
1 file changed, 1 insertion(+)
--- linux-2.6.13.y.orig/security/keys/request_key_auth.c
+++ linux-2.6.13.y/security/keys/request_key_auth.c
@@ -96,6 +96,7 @@ static void request_key_auth_destroy(str
kenter("{%d}", key->serial);
key_put(rka->target_key);
+ kfree(rka);
} /* end request_key_auth_destroy() */
From: Dave Jones <davej@redhat.com>
Please consider for next 2.6.13, it is a minor security issue allowing
users to turn on drm debugging when they shouldn''t...
This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/char/drm/drm_stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.13.y.orig/drivers/char/drm/drm_stub.c
+++ linux-2.6.13.y/drivers/char/drm/drm_stub.c
@@ -47,7 +47,7 @@ MODULE_PARM_DESC(cards_limit, "Maximum n
MODULE_PARM_DESC(debug, "Enable debug output");
module_param_named(cards_limit, drm_cards_limit, int, 0444);
-module_param_named(debug, drm_debug, int, 0666);
+module_param_named(debug, drm_debug, int, 0600);
drm_head_t **drm_heads;
struct drm_sysfs_class *drm_class;
From: Pavel Roskin <proski@gnu.org>
The orinoco driver can send uninitialized data exposing random pieces of
the system memory. This happens because data is not padded with zeroes
when its length needs to be increased.
Reported by Meder Kydyraliev <meder@o0o.nu>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/orinoco.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-2.6.13.y.orig/drivers/net/wireless/orinoco.c
+++ linux-2.6.13.y/drivers/net/wireless/orinoco.c
@@ -502,9 +502,14 @@ static int orinoco_xmit(struct sk_buff *
return 0;
}
- /* Length of the packet body */
- /* FIXME: what if the skb is smaller than this? */
- len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
+ /* Check packet length, pad short packets, round up odd length */
+ len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
+ if (skb->len < len) {
+ skb = skb_padto(skb, len);
+ if (skb == NULL)
+ goto fail;
+ }
+ len -= ETH_HLEN;
eh = (struct ethhdr *)skb->data;
@@ -556,8 +561,7 @@ static int orinoco_xmit(struct sk_buff *
p = skb->data;
}
- /* Round up for odd length packets */
- err = hermes_bap_pwrite(hw, USER_BAP, p, ALIGN(data_len, 2),
+ err = hermes_bap_pwrite(hw, USER_BAP, p, data_len,
txfid, data_off);
if (err) {
printk(KERN_ERR "%s: Error %d writing packet to
BAP\n",
Horms
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6?kernel
On Sun, Oct 09, 2005 at 01:28:21PM +0200, Andreas Metzler wrote:> In gmane.linux.debian.devel.kernel Martin Schulze <joey@infodrom.org> wrote: > > Moritz Muehlenhoff wrote: > >> Hi Horms / security team, > >> I found three more security related reports/patches on linux-kernel. > [...] > > This is CAN-2005-3119 and... uh... not supposed to be public yet... > > http://www.ussg.iu.edu/hypermail/linux/kernel/0510.0/1860.html > cu andreasThanks, that seems to be included in 2.6.13.4, I''ll go through that entire patch set ASAP. -- Horms
On Sun, Oct 09, 2005 at 12:18:54PM +0200, Moritz Muehlenhoff wrote:> Hi Horms / security team, > I found three more security related reports/patches on linux-kernel.Below are my annotations of 2.6.13.4 for all sarge and beyond kernels. I''m particularly interested in someone checking my backports of the sparc64 problem (not security). The attached document currently resides in: http://svn.debian.org/wsvn/kernel/people/horms/patch_notes/2.6-stable/2.6.13.4?op=file&rev=0&sc=0 -- Horms -------------- next part -------------- Version: 2.6.13.4 URL: http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=tree;f=2.6.13.4 * ieee1394/sbp2: fixes for hot-unplug and module unloading ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.patch Security: No 2.6.13: applied 2.6.12: added to svn; ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.patch 2.6.8-sarge: added to svn; ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.dpatch 2.6.8-sarge-security: not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable; not a security fix * [SECURITY] orinoco: Information leakage due to incorrect padding orinoco-info-leak.patch Security: Yes; Should request CVE 2.6.13: applied 2.6.12: added to svn; orinoco-info-leak.patch 2.6.8-sarge: added to svn; backported; orinoco-info-leak.dpatch 2.6.8-sarge-security: added to svn; backported; orinoco-info-leak.dpatch 2.4.27-sid/sarge: added to svn; backported; 192_orinoco-info-leak.diff 2.4.27-sarge-security: added to svn; backported; 192_orinoco-info-leak.diff * [TCP]: BIC coding bug in Linux 2.6.13 tcp-congestion-control-bug.patch Security: pending examination: 2.6.13: applied 2.6.12: not vulnerable 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable; not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable; not a security fix * [SECURITY] Fix drm ''debug'' sysfs permissions drm-module_param-permissions-fix.patch Security: Yes; Should request CVE 2.6.13: applied 2.6.12: added to svn; drm-module_param-permissions-fix.patch 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable * [SPARC64]: Fix userland FPU state corruption. fix-sparc64-fpu-register-corruption.patch Security: No 2.6.13: applied 2.6.12: added to svn; backport; fix-sparc64-fpu-register-corruption.patch 2.6.8-sarge: added to svn; backport; fix-sparc64-fpu-register-corruption.dpatch 2.6.8-sarge-security: not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable N.B: Could someone please look at these backports. They were trivial enough, but I have no way of testing them, nor do I have a good grasp of sparc assembly. I know this bug was painful to find, so presumably a miss-fix would be simmilarly painful. -- Horms * Avoid ''names_cache'' memory leak with CONFIG_AUDITSYSCALL plug-names_cache-memleak.patch Security: No 2.6.13: applied 2.6.12: added to svn; backport; plug-names_cache-memleak.dpatch 2.6.8-sarge: added to svn; backport; plug-names_cache-memleak.dpatch 2.6.8-sarge-security: not a security fix 2.4.27-sid/sarge: added to svn; backport; 193_plug-names_cache-memleak.diff 2.4.27-sarge-security: pending examination * [SECURITY] key: plug request_key_auth memleak See CAN-2005-3119 key-rka-memleak.patch Security: Yes; CAN-2005-3119 2.6.13: applied 2.6.12: not vulnerable 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable
On Sun, Oct 09, 2005 at 12:18:54PM +0200, Moritz Muehlenhoff wrote:> Hi Horms / security team, > I found three more security related reports/patches on linux-kernel.Below are my annotations of 2.6.13.4 for all sarge and beyond kernels. The CONFIG_AUDITSYSCALL one seems to be security, but we don''t have a CVE. Ditto for the orinoco and drm bugs, but thats already being delt with. I''m particularly interested in someone checking my backports of the sparc64 problem (not security). The attached document currently resides in: http://svn.debian.org/wsvn/kernel/people/horms/patch_notes/2.6-stable/2.6.13.4?op=file&rev=0&sc=0 -- Horms -------------- next part -------------- Version: 2.6.13.4 URL: http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=tree;f=2.6.13.4 * ieee1394/sbp2: fixes for hot-unplug and module unloading ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.patch Security: No 2.6.13: applied 2.6.12: added to svn; ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.patch 2.6.8-sarge: added to svn; ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.dpatch 2.6.8-sarge-security: not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable; not a security fix * [SECURITY] orinoco: Information leakage due to incorrect padding orinoco-info-leak.patch Security: Yes; Should request CVE 2.6.13: applied 2.6.12: added to svn; orinoco-info-leak.patch 2.6.8-sarge: added to svn; backported; orinoco-info-leak.dpatch 2.6.8-sarge-security: added to svn; backported; orinoco-info-leak.dpatch 2.4.27-sid/sarge: added to svn; backported; 192_orinoco-info-leak.diff 2.4.27-sarge-security: added to svn; backported; 192_orinoco-info-leak.diff * [TCP]: BIC coding bug in Linux 2.6.13 tcp-congestion-control-bug.patch Security: No 2.6.13: applied 2.6.12: not vulnerable 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable; not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable; not a security fix * [SECURITY] Fix drm ''debug'' sysfs permissions drm-module_param-permissions-fix.patch Security: Yes; Should request CVE 2.6.13: applied 2.6.12: added to svn; drm-module_param-permissions-fix.patch 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable * [SPARC64]: Fix userland FPU state corruption. fix-sparc64-fpu-register-corruption.patch Security: No 2.6.13: applied 2.6.12: added to svn; backport; fix-sparc64-fpu-register-corruption.patch 2.6.8-sarge: added to svn; backport; fix-sparc64-fpu-register-corruption.dpatch 2.6.8-sarge-security: not a security fix 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable N.B: Could someone please look at these backports. They were trivial enough, but I have no way of testing them, nor do I have a good grasp of sparc assembly. I know this bug was painful to find, so presumably a miss-fix would be simmilarly painful. -- Horms * [SECURITY] Avoid ''names_cache'' memory leak with CONFIG_AUDITSYSCALL plug-names_cache-memleak.patch Security: Yes; Should request CVE 2.6.13: applied 2.6.12: added to svn; backport; plug-names_cache-memleak.dpatch 2.6.8-sarge: added to svn; backport; plug-names_cache-memleak.dpatch 2.6.8-sarge-security: added to svn; backport; plug-names_cache-memleak.dpatch 2.4.27-sid/sarge: added to svn; backport; 193_plug-names_cache-memleak.diff 2.4.27-sarge-security: added to svn; backport; 193_plug-names_cache-memleak.diff * [SECURITY] key: plug request_key_auth memleak See CAN-2005-3119 key-rka-memleak.patch Security: Yes; CAN-2005-3119 2.6.13: applied 2.6.12: not vulnerable 2.6.8-sarge: not vulnerable 2.6.8-sarge-security: not vulnerable 2.4.27-sid/sarge: not vulnerable 2.4.27-sarge-security: not vulnerable
Andreas Metzler
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6?kernel
In gmane.linux.debian.devel.kernel Martin Schulze <joey@infodrom.org> wrote:> Moritz Muehlenhoff wrote: >> Hi Horms / security team, >> I found three more security related reports/patches on linux-kernel.[...]> This is CAN-2005-3119 and... uh... not supposed to be public yet...http://www.ussg.iu.edu/hypermail/linux/kernel/0510.0/1860.html cu andreas -- The ''Galactic Cleaning'' policy undertaken by Emperor Zhark is a personal vision of the emperor''s, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde
Horms
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6 kernel
On Sun, Oct 09, 2005 at 12:18:54PM +0200, Moritz Muehlenhoff wrote:> Hi Horms / security team, > I found three more security related reports/patches on linux-kernel.As mentioned elsewhere, the first (request_key_auth memleek) is CAN-2005-3119. Can we get CAN numbers for the other two?> > Cheers, > Moritz > > From: David Howells <dhowells@redhat.com> > > Plug request_key_auth memleak. This can be triggered by unprivileged > users, so is local DoS. > > Signed-off-by: Chris Wright <chrisw@osdl.org> > Signed-Off-By: David Howells <dhowells@redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > --- > security/keys/request_key_auth.c | 1 + > 1 file changed, 1 insertion(+) > > --- linux-2.6.13.y.orig/security/keys/request_key_auth.c > +++ linux-2.6.13.y/security/keys/request_key_auth.c > @@ -96,6 +96,7 @@ static void request_key_auth_destroy(str > kenter("{%d}", key->serial); > > key_put(rka->target_key); > + kfree(rka); > > } /* end request_key_auth_destroy() */ > > > From: Dave Jones <davej@redhat.com> > > Please consider for next 2.6.13, it is a minor security issue allowing > users to turn on drm debugging when they shouldn''t... > > This fell through the cracks. Until Josh pointed me at > http://bugs.gentoo.org/show_bug.cgi?id=107893 > > Signed-off-by: Chris Wright <chrisw@osdl.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > --- > drivers/char/drm/drm_stub.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2.6.13.y.orig/drivers/char/drm/drm_stub.c > +++ linux-2.6.13.y/drivers/char/drm/drm_stub.c > @@ -47,7 +47,7 @@ MODULE_PARM_DESC(cards_limit, "Maximum n > MODULE_PARM_DESC(debug, "Enable debug output"); > > module_param_named(cards_limit, drm_cards_limit, int, 0444); > -module_param_named(debug, drm_debug, int, 0666); > +module_param_named(debug, drm_debug, int, 0600); > > drm_head_t **drm_heads; > struct drm_sysfs_class *drm_class; > > > From: Pavel Roskin <proski@gnu.org> > > The orinoco driver can send uninitialized data exposing random pieces of > the system memory. This happens because data is not padded with zeroes > when its length needs to be increased. > > Reported by Meder Kydyraliev <meder@o0o.nu> > > Signed-off-by: Pavel Roskin <proski@gnu.org> > Signed-off-by: Chris Wright <chrisw@osdl.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > --- > drivers/net/wireless/orinoco.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > --- linux-2.6.13.y.orig/drivers/net/wireless/orinoco.c > +++ linux-2.6.13.y/drivers/net/wireless/orinoco.c > @@ -502,9 +502,14 @@ static int orinoco_xmit(struct sk_buff * > return 0; > } > > - /* Length of the packet body */ > - /* FIXME: what if the skb is smaller than this? */ > - len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN); > + /* Check packet length, pad short packets, round up odd length */ > + len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN); > + if (skb->len < len) { > + skb = skb_padto(skb, len); > + if (skb == NULL) > + goto fail; > + } > + len -= ETH_HLEN; > > eh = (struct ethhdr *)skb->data; > > @@ -556,8 +561,7 @@ static int orinoco_xmit(struct sk_buff * > p = skb->data; > } > > - /* Round up for odd length packets */ > - err = hermes_bap_pwrite(hw, USER_BAP, p, ALIGN(data_len, 2), > + err = hermes_bap_pwrite(hw, USER_BAP, p, data_len, > txfid, data_off); > if (err) { > printk(KERN_ERR "%s: Error %d writing packet to BAP\n",-- Horms
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6 kernel
Horms wrote:> > I found three more security related reports/patches on linux-kernel. > > As mentioned elsewhere, the first (request_key_auth memleek) is CAN-2005-3119. > Can we get CAN numbers for the other two?Here they are:> > From: Dave Jones <davej@redhat.com> > > > > Please consider for next 2.6.13, it is a minor security issue allowing > > users to turn on drm debugging when they shouldn''t...=====================================================Candidate: CAN-2005-3179 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3179 Reference: CONFIRM:http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=d7067d7d1f92cba14963a430cfbd53098cbbc8fd Reference: CONFIRM:http://bugs.gentoo.org/show_bug.cgi?id=107893 drm.c in Linux kernel 2.6.13 and earlier creates a debug file in sysfs with world-readable and world-writable permissions, which allows local users to enable DRM debugging and obtain sensitive information.> > From: Pavel Roskin <proski@gnu.org> > > > > The orinoco driver can send uninitialized data exposing random pieces of > > the system memory. This happens because data is not padded with zeroes > > when its length needs to be increased.=====================================================Candidate: CAN-2005-3180 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3180 Reference: CONFIRM:http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=feecb2ffde28639e60ede769c6f817dc536c677b The Orinoco driver (orinoco.c) in Linux kernel 2.6.13 and earlier does not properly clear memory from a previously used packet whose length is increased, which allows remote attackers to obtain sensitive information. Cheers, Moritz
Horms
2006-Mar-13 12:28 UTC
[Secure-testing-team] Re: Three more security problems in the 2.6 kernel
On Tue, Oct 11, 2005 at 10:30:42PM +0200, Moritz Muehlenhoff wrote:> Horms wrote: > > > I found three more security related reports/patches on linux-kernel. > > > > As mentioned elsewhere, the first (request_key_auth memleek) is CAN-2005-3119. > > Can we get CAN numbers for the other two? > > Here they are:Thanks, I''ll get them into svn and my patch_notes space ASAP.> > > From: Dave Jones <davej@redhat.com> > > > > > > Please consider for next 2.6.13, it is a minor security issue allowing > > > users to turn on drm debugging when they shouldn''t... > > =====================================================> Candidate: CAN-2005-3179 > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3179 > Reference: CONFIRM:http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=d7067d7d1f92cba14963a430cfbd53098cbbc8fd > Reference: CONFIRM:http://bugs.gentoo.org/show_bug.cgi?id=107893 > > drm.c in Linux kernel 2.6.13 and earlier creates a debug file in sysfs > with world-readable and world-writable permissions, which allows local > users to enable DRM debugging and obtain sensitive information. > > > > > From: Pavel Roskin <proski@gnu.org> > > > > > > The orinoco driver can send uninitialized data exposing random pieces of > > > the system memory. This happens because data is not padded with zeroes > > > when its length needs to be increased. > > =====================================================> Candidate: CAN-2005-3180 > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3180 > Reference: CONFIRM:http://www.kernel.org/hg/linux-2.6/?cmd=changeset;node=feecb2ffde28639e60ede769c6f817dc536c677b > > The Orinoco driver (orinoco.c) in Linux kernel 2.6.13 and earlier does > not properly clear memory from a previously used packet whose length > is increased, which allows remote attackers to obtain sensitive > information.-- Horms