Determining applicability is hard

Determining applicability is hard

Posted May 1, 2008 0:59 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
In reply to: Determining applicability is hard by jreiser
Parent article: Ksplice: kernel patches without reboots

I'm not sure I follow. Let's look at a patch, shall we?

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -983,6 +983,8 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
        int i;
        unsigned int vm_flags;
 
+       if (len <= 0)
+               return 0;
        /* 
         * Require read or write permissions.
         * If 'force' is set, we only require the "MAY" flags.

(If our dear editor is reading, he might get a chuckle out of my selection.)

I would argue that "get_user_pages" has plenty of side effects in memory on nearly all interesting execution paths. And yet, I imagine this splicing trick works just fine with this patch.

We've changed the algorithm for "get_user_pages" so it doesn't do strange and mysterious things (occasionally leading to local-root exploits) when the length is negative. Since we didn't free all other user pages ahead of time, previous outputs are "in view."

What I *will* buy is if someone exploited this hole on a running kernel, patching the bug after the fact won't cause the bogus allocation to disappear. But, in that case, you're b0rked anyway.

Your argument applies only when valid inputs give materially different outputs. Note that I say materially different. If I change Initial Sequence Number generation in my TCP/IP stack (a noticeable change!), I don't have to close all other TCP connections that are in the process of being established. I just get better behavior going forward.

---

(Log in to post comments)