Bug#787191: Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1

[Michael Biebl]

Am 16.06.2015 um 17:21 schrieb Faidon Liambotis:
> Hi,
> 
> Any news about this? Can I help in any way?
> 
> Thanks,
> Faidon
> 
> On Fri, May 29, 2015 at 05:41:24PM +0300, Faidon Liambotis wrote:
>> On Mon, Apr 06, 2015 at 08:50:58PM +0100, Ben Hutchings wrote:
>>> It looks the same as this problem:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705
>>> http://thread.gmane.org/gmane.linux.ubuntu.devel.kernel.general/39123/
>>
>> I just encountered this bug while trying to install jessie on a Dell
>> PowerEdge R610 with a SAS 6/iR (fairly recent, much more than 1950s).
>> The kernel crashes while in d-i and installation fails. I also tried
>> with a nightly d-i with Linux 4.0 -- same issue.
>>
>> Ironically, I found this bug report, clicked through the referenced
>> links, only to discover I had previously investigated this when
>> installling a similar server with Ubuntu 14.04 and I've even replied to
>> the Launchpad bug above... I can confirm it's the exact same bug. Note
>> that it was also covered by LWN(!): https://lwn.net/Articles/611226/
>>
>> It's disappointing that this bug hasn't been fixed yet upstream and
>> especially the part where mptsas' error handling is broken and the
>> kernel crashes instead of gracefully failing. This is a different,
>> secondary, bug that is just triggered by the timeout.
>>
>> In any case, there seems to have been /some/ improvement upstream on
>> this. systemd has increased the timeout from 30s to 60s (2e92633) and
>> subsequently to 180s (b5338a1), in commits that are both included in
>> v217. They have also made this a kernel command-line option
>> (udev.event-timeout & rd.udev.event-timeout) but those are more invasive
>> patches.
>>
>> My working servers with Ubuntu 12.04 & 14.04 indicate on their dmesg
>> that the probe time is somewhere between 18-31s, so 180s would
>> definitely fix the effect of this bug.
>>
>> The commits above aren't directly backportable to v215 as the upstream
>> code has changed significantly but the very simple patch attached is the
>> equivalent fix for v215 (it's untested, though).
>>
>> This affects a large number of Dell systems (~100 alone in my case) and
>> there is no practical workaround, so it'd be great if this was fixed in
>> a jessie point release.
>>
>> Best,
>> Faidon
> 
>> diff --git a/src/udev/udevd.c b/src/udev/udevd.c
>> index a45d324..072499c 100644
>> --- a/src/udev/udevd.c
>> +++ b/src/udev/udevd.c
>> @@ -1415,7 +1415,7 @@ int main(int argc, char *argv[])
>>                                  if (worker->state != WORKER_RUNNING)
>>                                          continue;
>>  
>> -                                if ((now(CLOCK_MONOTONIC) - worker->event_start_usec) > 30 * USEC_PER_SEC) {
>> +                                if ((now(CLOCK_MONOTONIC) - worker->event_start_usec) > 180 * USEC_PER_SEC) {
>>                                          log_error("worker [%u] %s timeout; kill it", worker->pid,
>>                                              worker->event ? worker->event->devpath : "<idle>");
>>                                          kill(worker->pid, SIGKILL);
> 

Looking more into this, this patch might actually not be sufficient /
the right fix and we might need the following instead:

$ git diff
diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c
index 5213a4a..66d8c40 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -48,7 +48,7 @@ struct udev_event *udev_event_new(struct udev_device *dev)
         udev_list_init(udev, &event->seclabel_list, false);
         event->fd_signal = -1;
         event->birth_usec = now(CLOCK_MONOTONIC);
-        event->timeout_usec = 30 * 1000 * 1000;
+        event->timeout_usec = 180 * 1000 * 1000;
         return event;
 }



Anyone willing to test this patch? I can provide pre-built packages for
i386 and amd64.
Note: if we want to get this into 8.2, this should happen quickly. The
deadline for 8.2. is this weekend.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150828/6044cc69/attachment-0002.sig>