r4521 - people/micah

Micah Anderson micah at costa.debian.org
Tue Oct 18 17:29:55 UTC 2005


Author: micah
Date: 2005-10-18 17:29:54 +0000 (Tue, 18 Oct 2005)
New Revision: 4521

Modified:
   people/micah/pending_CVE_requests
Log:
Reformatted file, submitted CVEs noted as STATUS: Submitted


Modified: people/micah/pending_CVE_requests
===================================================================
--- people/micah/pending_CVE_requests	2005-10-18 11:58:19 UTC (rev 4520)
+++ people/micah/pending_CVE_requests	2005-10-18 17:29:54 UTC (rev 4521)
@@ -1,172 +1,216 @@
-
-Draft text for CVE:
-A local denial of service was discovered in the ptrace code for ia64 in
-linux-2.6.8 enabling unprivledged users to trigger an oops when
-CONFIG_PREEMPT is enabled in the kernel configuration.
-TODO: dannf looking for HP-developed exploit code
-dannf: The exploit code was tested on 2.6.8-2.6.10, only 2.6.8 demonstrated the problem.
-dannf: It was very reproducible with PREEMPT enabled, but not at all reproducible without PREEMPT
-dannf: However; we were unable to find any changeset in bitkeeper that we could identify as a fix for this.
-dannf: Since then, the exploit code has been lost and the developer has lost it.
-dannf:
-dannf: Since no other distributions appear to be vulnerable, and a fix is difficult to find, I believe
-dannf: we should disable PREEMPT in a security update for ia64.  Unless we can find the exploit code, it may
-dannf: not be worth allocating a CAN ID.  Disabling PREEMPT is a ABI change, so it would be best to
-dannf: coalesce this with another ABI event.
-
-Patches included in 2.6.8-16sarge1:
-
-* fs-exec-posix-timers-leak-1.dpatch,
-Draft text for CVE:
+1. fs-exec-posix-timers-leak-1.dpatch 
+STATUS: Submitted
+======================================================
+Candidate:
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@414b332fsZQvEUsfzKJIo-q2_ZH0hg
+REFERENCE: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1107.html
 A potential local denial of service was discovered in Linux 2.6 prior to 2.6.9.
 Exec fails to clean up posix-timers, leaving lingering
 timers around that could kill processes with unexpected signals. 
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@414b332fsZQvEUsfzKJIo-q2_ZH0hg
-URL: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1107.html
 
-* fs-exec-posix-timers-leak-2.dpatch
-Draft CVE text:
-Pending signals maybe lost during a multithreaded exec in Linux 2.6 kernels
-prior to 2.6.10.  This is a violation of the POSIX specification, and can give
-unexpected results when a signal delivered during an exec vanishes.
-dannf: I don't think this is a security problem; the patch name is a misnomer -
-dannf: it was submitted at the same time as a patch that fixes a leak, but this
-dannf: patch actual prevents a signal loss.
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@4174ac1exFxpMg163OsRuPZLQrlBKg
-URL: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1107.html
 
-* net-bridge-forwarding-poison-1.dpatch,
-  net-bridge-forwarding-poison-2.dpatch:
-Draft CVE text:
+2. net-bridge-forwarding-poison-1.dpatch  
+   net-bridge-forwarding-poison-2.dpatch:
+STATUS: Submitted
+NOTES:
+M: the following are pre-requisites: net-bridge-mangle-oops-1.dpatch 
+M: net-bridge-mangle-oops-2.dpatch
+dannf: This patch appears applicable to 2.6.0->2.6.11 (as noted above)
+======================================================
+Candidate:
+CONFIRM: URL: http://linux.bkbits.net:8080/linux-2.6/cset@412d2246sXjFQD6OadAB57YWvqR9vQ
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@1.3097.18.19?nav=index.html|src/|src/net|src/net/bridge|related/net/bridge/br_input.c
 Spoofed source addresses on the public facing side of a bridge can
 cause packet leaks due to poisoning of the bridge forwarding table by
 frames that have been dropped by filtering.  This bug has been fixed in Linux
 2.6.12 and later.
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@412d2246sXjFQD6OadAB57YWvqR9vQ
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@1.3097.18.19?nav=index.html|src/|src/net|src/net/bridge|related/net/bridge/br_input.c
-M: the following are pre-requisites:
-M: net-bridge-mangle-oops-1.dpatch
-M: net-bridge-mangle-oops-2.dpatch
-dannf: This patch appears applicable to 2.6.0->2.6.11 (as noted above)
 
-* net-rose-ndigis-verify.dpatch
-Draft CVE text:
-rose_rt_ioctl() in Linux 2.6 kernels prior to 2.6.12 did not sanity check the
-number of digipeats passed it.  A value too large can cause a couple of code
-paths to run off of the end of allocated arrays, creating a potential DoS
-attack vector.
+
+3. net-rose-ndigis-verify.dpatch
+STATUS: Submitted
+NOTES:
 dannf> I ran the above draft text by Chris Wright & he agrees.  Note that
 dannf> CAP_NET_ADMIN is required to use the interface, which makes this issue
 dannf> quite minor
-URL: http://linux.bkbits.net:8080/linux-2.6/diffs/net/rose/rose_route.c@1.16?nav=index.html|src/|src/net|src/net/rose|related/net/rose/rose_route.c|cset@1.2009.1.46
-URL: http://lkml.org/lkml/2005/5/23/169
+======================================================
+Candidate:
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/diffs/net/rose/rose_route.c@1.16?nav=index.html|src/|src/net|src/net/rose|related/net/rose/rose_route.c|cset@1.2009.1.46
+REFERENCE: http://lkml.org/lkml/2005/5/23/169
+The rose_rt_ioctl() function in Linux 2.6 kernels prior to 2.6.12 did not sanity check the
+number of digipeats passed it.  A value too large can cause a couple of code
+paths to run off of the end of allocated arrays, creating a potential denial of service
+attack vector.
 
-* sound-usb-usbaudio-unplug-oops.dpatch
-    [Security] Prevent oops & dead keyboard on usb unplugging while the device
-    is being used.
-URL: http://lkml.org/lkml/2005/5/23/152
-URL: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=230cd5e24853ed4dd960461989b8ed0986d37a99
-TODO: How is this a security patch?
+
+4. net-ipv4-ipvs-conn_tab-race.dpatch
+STATUS: Submitted
+======================================================
+Candidate:
+CONFIRM:http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=e684f066dff5628bb61ad1912de6e8058b5b4c7d
+REFERENCE:http://lkml.org/lkml/2005/6/23/249
+REFERENCE:http://lkml.org/lkml/2005/6/24/173
+A race condition resulting in a potential denial of service was
+discovered in ip_vs_conn_flush in 2.6 kernels earlier than 2.6.13 and
+2.4 kernels earlier than 2.4.32-pre2 on SMP systems. This race
+condition involves the lock release and re-aquisition of the list
+iterator loop resulting in the connection pointer to be set to NULL
+and then subsequently dereferenced, resulting in an oops.
+
+
+5. netfilter-NAT-memory-corruption.dpatch (2.6.8)
+   174_net-ipv4-netfilter-nat-mem.diff (2.4.27)
+STATUS: Submitted
+NOTES: 
+M> fixed in 2.6.12.3
+M> how is this a security issue?
+dannf> I'm not positive it is; but if it is, this description should do
+M> I think its safer to assume it is if we aren't positive, so I'll submit it
+======================================================
+Candidate:
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@1.3596.79.34?nav=index.html|src/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_nat_proto_udp.c
+A potential memory corruption bug exists in the NAT code in Linux
+kernels prior to 2.6.13 and 2.4.32-rc1.  The portptr pointing to the
+port in the conntrack tuple is declared static, which could result in
+memory corruption when two packets of the same protocol are NATed at
+the same time and one conntrack goes away.  A malicious machine on the
+same network could potentially use this to initiate a DoS attack.
+
+
+6. fs-exec-posix-timers-leak-2.dpatch
+STATUS: Not Submitted
+NOTES:
+dannf: I don't think this is a security problem; the patch name is a misnomer -
+dannf: it was submitted at the same time as a patch that fixes a leak, but this
+dannf: patch actual prevents a signal loss.
+Draft CVE text:
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@4174ac1exFxpMg163OsRuPZLQrlBKg
+REFERENCE: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/1107.html
+Pending signals may be lost during a multithreaded exec in Linux 2.6 kernels
+prior to 2.6.10.  This is a violation of the POSIX specification, and can give
+unexpected results when a signal delivered during an exec vanishes.
+
+
+7. sound-usb-usbaudio-unplug-oops.dpatch
+STATUS: Not submitted
+NOTES:
+M: How is this a security patch?
 dannf> I don't think it is; if you have physical access enough to unplug a keyboard, you could also smash
 dannf> the keyboard with a hammer and stick gum in the USB ports - this won't solve that problem.
+REFERENCE: http://lkml.org/lkml/2005/5/23/152
+CONFIRM: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=230cd5e24853ed4dd960461989b8ed0986d37a99
 Draft CVE text:
 Detaching a USB keyboard in Linux 2.6 kernels prior to 2.6.12 may trigger an oops and leave the keyboard
 unusable until a reboot.
 
-* net-ipv4-ipvs-conn_tab-race.dpatch
-[Security] Fix race condition on ip_vs_conn_tab list modification
-Draft CVE text: 
-A race condition resulting in a potential DoS was discovered in
-ip_vs_conn_flush in 2.6 kernels earlier than 2.6.13 and 2.4 kernels
-earlier than 2.4.32-pre2 on SMP systems. A race condition
-exists involving the lock release and re-aquisition of the list
-iterator loop resulting in the connection pointer to be set to NULL
-and then subsequently dereferenced, resulting in an oops.
-URL: http://lkml.org/lkml/2005/6/23/249
-URL: http://lkml.org/lkml/2005/6/24/173
-URL: http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=e684f066dff5628bb61ad1912de6e8058b5b4c7d
 
-* asm-i386-mem-clobber.dpatch:
-URL: http://lkml.org/lkml/2005/6/27/348
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@1.3349?nav=index.html|src/|src/include|src/include/asm-i386|related/include/asm-i386/string.h
-TODO: CVE text
-TODO: Security issue?  dannf> It's noted as *not* a security issue in patches/debian/series/2.6.8-16sarge1;
-TODO:                         though its in the changelog, it isn't applied in that version
-TODO: Fixed in Upstream 2.6.12.2
+8. asm-i386-mem-clobber.dpatch
+STATUS: Not submitted
+NOTES:
+M: Fixed in Upstream 2.6.12.2
+M: Security issue?  
+dannf> It's noted as *not* a security issue in patches/debian/series/2.6.8-16sarge1;
+       though its in the changelog, it isn't applied in that version
+REFERENCE: http://lkml.org/lkml/2005/6/27/348
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@1.3349?nav=index.html|src/|src/include|src/include/asm-i386|related/include/asm-i386/string.h
+Draft CVE text:
 
 
-* net-netlink-autobind-return.dpatch
+9. net-netlink-autobind-return.dpatch
+STATUS: Not submitted
+NOTES:
+M: How is this a security issue?
+dannf> I don't think it is
 Draft CVE text:
-    Make sure netlink_autobind() propagates the error return from
-    netlink_insert().  Otherwise, callers will not see the error as they
-    should and thus try to operate on a socket with a zero pid, which is very
-    bad.
-TODO: How is this a security issue?
-dannf> I don't think it is
+Make sure netlink_autobind() propagates the error return from
+netlink_insert().  Otherwise, callers will not see the error as they
+should and thus try to operate on a socket with a zero pid, which is
+very bad.
 
-* arch-ia64-ptrace-getregs-putregs.dpatch
-    [Security, ia64] Fix unchecked user-memory accesses in ptrage_getregs()
-    and ptrace_setregs.
+10. arch-ia64-ptrace-getregs-putregs.dpatch
+STATUS: Not submitted
+NOTES:
 M: dannf says this is a pre-requisite for 2005-1761
+M: [Security, ia64] Fix unchecked user-memory accesses in ptrage_getregs()
+M: and ptrace_setregs.
 
-* ppc32-time_offset-misuse.dpatch
-URL: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=8f399a7448e0b58eae969426f61b7e81d55d2639
-TODO: CVE text (how is this a security issue?)
+
+11. ppc32-time_offset-misuse.dpatch
+STATUS: Not submitted
+NOTES:
+M: need CVE text (how is this a security issue?)
 dannf: The only way I can see this as being a security issue is if somehow a malicious NTP server could take
 dannf: advantage of this to set time_offset to a value that somehow makes the system oops or something - but
 dannf: since it already checks to see if this is non-zero, I don't think that's likely.
+REFERENCE: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.12.y.git;a=commitdiff;h=8f399a7448e0b58eae969426f61b7e81d55d2639
 
-* netfilter-NAT-memory-corruption.dpatch (2.6.8)
-* 174_net-ipv4-netfilter-nat-mem.diff (2.4.27)
-fixed in 2.6.12.3
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@1.3596.79.34?nav=index.html|src/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_nat_proto_udp.c
-TODO: how is this a security issue?
-dannf> I'm not positive it is; but if it is, this description should do.
-Draft CVE Text:
-A potential memory corruption bug exists in the NAT code in Linux kernels prior to 2.6.13 and 2.4.32-rc1.
-The portptr pointing to the port in the conntrack tuple is declared static, which could result in memory
-corruption when two packets of the same protocol are NATed at the same time and one conntrack goes away.  A
-malicious machine on the same network could potentially use this to initiate a DoS attack.
 
-* netfilter-ip_conntrack_untracked-refcount.dpatch
-TODO: CVE text (how is this a security issue?)
-      dannf> I don't see how it is either
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@1.3596.79.35?nav=index.html|src/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_conntrack_core.c
-URL: http://lkml.org/lkml/2005/8/3/35
+12. netfilter-ip_conntrack_untracked-refcount.dpatch
+STATUS: Not submitted
+NOTES:
+M: need CVE text (how is this a security issue?)
+dannf> I don't see how it is either
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@1.3596.79.35?nav=index.html|src/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_conntrack_core.c
+REFERENCE: http://lkml.org/lkml/2005/8/3/35
 
-* sys_get_thread_area-leak.dpatch
-URL: http://linux.bkbits.net:8080/linux-2.6/cset@1.3700.4.106?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel|related/arch/i386/kernel/process.c
-URL: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=71ae18ec690953e9ba7107c7cc44589c2cc0d9f1
-URL: http://lkml.org/lkml/2005/8/3/36
-Draft CVE Text:
-sys_get_thread_area() in Linux 2.6 kernels prior to 2.6.12.4 and 2.6.13 does not entirely clear a user_desc
-structure before copying it to userspace, resulting in a small information leak.
+13. sys_get_thread_area-leak.dpatch
+STATUS: Submitted
+NOTES:
+======================================================
+Candidate:
+CONFIRM: http://linux.bkbits.net:8080/linux-2.6/cset@1.3700.4.106?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel|related/arch/i386/kernel/process.c
+CONFIRM: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=71ae18ec690953e9ba7107c7cc44589c2cc0d9f1
+REFERENCE: http://lkml.org/lkml/2005/8/3/36
+The sys_get_thread_area function in Linux 2.6 kernels prior to 2.6.12.4 and
+2.6.13 does not entirely clear a user_desc structure before copying it
+to userspace, resulting in a small information leak.
 
-* fs_ext2_ext3_xattr-sharing.dpatch
-    [Security] Xattr sharing bug
-    See http://lists.debian.org/debian-kernel/2005/08/msg00238.html
-URL: http://lists.debian.org/debian-kernel/2005/08/msg00238.html
-URL: http://www.novell.com/linux/security/advisories/2005_18_kernel.html
-URL:
-http://acl.bestbits.at/pipermail/acl-devel/2005-February/001848.html
-Draft CVE Text:
-The ext2 and ext3 filesystems in Linux kernels prior to 2.6.11, may mistake two xattr structures as being
-identical when they differ only by the e_name_index field.  This can lead to a situation where the
+
+14. fs_ext2_ext3_xattr-sharing.dpatch
+STATUS: Submitted
+NOTES:
+======================================================
+Candidate:
+REFERENCE: http://lists.debian.org/debian-kernel/2005/08/msg00238.html
+REFERENCE: http://www.novell.com/linux/security/advisories/2005_18_kernel.html
+REFERENCE: http://acl.bestbits.at/pipermail/acl-devel/2005-February/001848.html
+The ext2 and ext3 filesystems in Linux kernels prior to 2.6.11, may
+mistake two xattr structures as being identical when they differ only
+by the e_name_index field.  This can lead to a situation where the
 default ACLs on a directory disappear.
-TODO: include 2.4 info -- I am confused because xattr.c doesn't exist in 2.4, asking horms
 
-Draft CVE Text:
+15. 184_arch-x86_64-ia32-ptrace32-oops.diff
+STATUS: Submitted
+NOTES:
 dannf> This is the only one in 2.4.27-10sarge1 I couldn't find a CAN for elsewhere...
-* 184_arch-x86_64-ia32-ptrace32-oops.diff
-URL: http://lkml.org/lkml/2005/1/5/245
-URL: http://linux.bkbits.net:8080/linux-2.4/cset@41dd3455GwQPufrGvBJjcUOXQa3WXA
-Mark Bellon discovered a bug in the ptrace32 code routine on x86_64 Linux 2.4 kernels prior to 2.4.29.
-The find_target routine failed to properly handle the case where find_task_by_pid() returns NULL.  This
-is a potential DoS attack vector as it is possible for local users to cause the kernel to oops.
+======================================================
+Candidate:
+REFERENCE: http://lkml.org/lkml/2005/1/5/245
+CONFIRM: http://linux.bkbits.net:8080/linux-2.4/cset@41dd3455GwQPufrGvBJjcUOXQa3WXA
+Mark Bellon discovered a bug in the ptrace32 code routine on x86_64
+Linux 2.4 kernels prior to 2.4.29.  The find_target routine failed to
+properly handle the case where find_task_by_pid() returns NULL.  This
+is a potential DoS attack vector as it is possible for local users to
+cause the kernel to oops.
 
+16.  ptrace ia64 CONFIG_PREEMPT issue
+STATUS: Not submitted
+NOTES:
+TODO: dannf looking for HP-developed exploit code
+dannf: The exploit code was tested on 2.6.8-2.6.10, only 2.6.8 demonstrated the problem.
+dannf: It was very reproducible with PREEMPT enabled, but not at all reproducible without PREEMPT
+dannf: However; we were unable to find any changeset in bitkeeper that we could identify as a fix for this.
+dannf: Since then, the exploit code has been lost and the developer has lost it.
+dannf:
+dannf: Since no other distributions appear to be vulnerable, and a fix is difficult to find, I believe
+dannf: we should disable PREEMPT in a security update for ia64.  Unless we can find the exploit code, it may
+dannf: not be worth allocating a CAN ID.  Disabling PREEMPT is a ABI change, so it would be best to
+dannf: coalesce this with another ABI event.
+Draft text for CVE:
+A local denial of service was discovered in the ptrace code for ia64 in
+linux-2.6.8 enabling unprivledged users to trigger an oops when
+CONFIG_PREEMPT is enabled in the kernel configuration.
 
 
-
 New patches horms has applied, need to investigate these
 orinoco and drm bugs:
 orinoco-info-leak.patch (in 2.6.13.3)




More information about the Kernel-svn-changes mailing list