[kernel] r5060 - patch-tracking/non-security

[Moritz Muehlenhoff]

Author: jmm-guest
Date: Wed Dec 21 10:41:47 2005
New Revision: 5060

Added:
   patch-tracking/non-security/
   patch-tracking/non-security/180_fs-isofs-ignored-parameters
   patch-tracking/non-security/sk_run_filter-sk_check_filter
Log:
start tracking issues that appeared to be security problems
at the first glance, but were ruled out by more checking.


Added: patch-tracking/non-security/180_fs-isofs-ignored-parameters
==============================================================================
--- (empty file)
+++ patch-tracking/non-security/180_fs-isofs-ignored-parameters	Wed Dec 21 10:41:47 2005
@@ -0,0 +1,24 @@
+isofs ignores any mount parameters after iocharset, map or session.
+http://lists.debian.org/debian-kernel/2005/08/msg00581.html
+
+Comment from Horms:
+Basically works like this.
+
+When a mount request is received by the kernel for isofs it processes
+the mount options in turn. If it encounters the iocharset, map
+or session option, then all subsequent options are ignored.
+(Ok, that was just a rewording of the text above :)
+
+So if a user can some how inject some mount options (say iocharset),
+before the ones specified by root in the fstab, then they might
+be able to do some nasties, like say mounting things with
+more generous permisions than was intended.
+
+But, a user runs mount, even if the mount is permitted in fstab,
+mount won't accept any options from the user. Well, at least in my
+testing.
+
+# mount /mnt/tmp/
+# umount /mnt/tmp/
+# mount -o uid=7100 /mnt/tmp/
+mount: only root can do that
\ No newline at end of file

Added: patch-tracking/non-security/sk_run_filter-sk_check_filter
==============================================================================
--- (empty file)
+++ patch-tracking/non-security/sk_run_filter-sk_check_filter	Wed Dec 21 10:41:47 2005
@@ -0,0 +1,49 @@
+I took a look over this, the patch that went into 2.6.15-rc3 is below.
+As Dave's comment suggets, this really only moves the check from 
+sk_run_filter() to sk_chk_filter(). I tried to see how it might
+be exploitable, but given the restriction of the check that
+was added to sk_chk_filter() (BPF_ALU|BPF_DIV|BPF_K) it only
+seems to apply to the case that was already guarded in sk_run_filter().
+
+-- 
+Horms
+
+commit fb0d366b0803571f06a5b838f02c6706fc287995
+tree 473d0e16f244ef7c7415d865419b7b0187f52a7f
+parent aa8751667dcd757dd9a711b51140adf181501c44
+author Kris Katterjohn <kjak at users.sourceforge.net> Sun, 20 Nov 2005 13:41:34 -0800
+committer David S. Miller <davem at davemloft.net> Sun, 20 Nov 2005 13:41:34 -0800
+
+    [NET]: Reject socket filter if division by constant zero is attempted.
+    
+    This way we don't have to check it in sk_run_filter().
+    
+    Signed-off-by: Kris Katterjohn <kjak at users.sourceforge.net>
+    Signed-off-by: David S. Miller <davem at davemloft.net>
+
+diff --git a/net/core/filter.c b/net/core/filter.c
+index 079c2ed..2841bfc 100644
+--- a/net/core/filter.c
++++ b/net/core/filter.c
+@@ -116,8 +116,6 @@ int sk_run_filter(struct sk_buff *skb, s
+ 			A /= X;
+ 			continue;
+ 		case BPF_ALU|BPF_DIV|BPF_K:
+-			if (fentry->k == 0)
+-				return 0;
+ 			A /= fentry->k;
+ 			continue;
+ 		case BPF_ALU|BPF_AND|BPF_X:
+@@ -320,6 +318,10 @@ int sk_chk_filter(struct sock_filter *fi
+ 			}
+ 		}
+ 
++		/* check for division by zero   -Kris Katterjohn 2005-10-30 */
++		if (ftest->code == (BPF_ALU|BPF_DIV|BPF_K) && ftest->k == 0)
++			return -EINVAL;
++
+ 		/* check that memory operations use valid addresses. */
+ 		if (ftest->k >= BPF_MEMWORDS) {
+ 			/* but it might not be a memory operation... */
+
+