Linux kernel null pointer

Unable to handle kernel NULL pointer.

Если твое ядро раньше работало стабильно, а сейчас начало валиться с такой ошибкой, то проверять надо железо (почти все): блок питания, память, диски/кабели, .

P.S. В дистрибутиве нормальное ядро. была ли веская причина компилировать самому, да еще ванильное?

Re: Unable to handle kernel NULL pointer.

Ну у меня сервак более 2-3 месяцев без перезагрузки не работал (так получалось), поэтому oops были если он долго без перезагрузки поработает. А если так случается, что я его перзагружу, до того как это случится — то вроде как и даже беспокоиться не о чем. Зачастило это последний год. Но раньше может не вылазило не потому что железо не глючило, а потому что я чаще пперезагружал. Хз — вот сам в непонятках. Но зависимость четкая — чем дольше без перезагрузки — тем выше веротняоть что глюкнет. Глюков вот прям сходу, сразу после перезагрузки не бывает.

А ядро своё: чтобы модули нельзя было загрузить (руткиты там всякие и пр). Я сконфигурил под свое железо и скомпилил монолитное ядро — без возможности загрузки других. В основном в целях безопасности. Ну и другие приемущества у него есть. USB и соответсвенно udev/hotplug не использую вообще.

Re: Unable to handle kernel NULL pointer.

> А ядро своё: чтобы модули нельзя было загрузить (руткиты там всякие и пр). Я сконфигурил под свое железо и скомпилил монолитное ядро — без возможности загрузки других

Если я получил возможность на некоторой системе загрузить в ядро свой модуль, то это значит что я имею на ней рута. И поверь, пересобрать на этой системе свое ядро из твоих исходников мне также труда не составит 🙂 Так что всякая чушь вида «чтоб не было руткита» и прочие «прадвинутые настройки для риальнай сикурности» чушь полная.

Источник

Linux kernel NULL-pointer dereference in memset from kzalloc

Quite by chance stumbled upon some code in kernel jungles and was a bit confused. There are two implementations of kzalloc() : in tools/virtio/linux/kernel.h and the main one in linux/slab.h. Obviously, in most cases the second one is used. But sometimes the «virtio» kzalloc() is used.

«virtio» kzalloc() looks like this:

My confusion is that «fake» kmalloc() used inside «tools» directory can return NULL-pointer. Also it looks like the memset() implementation doesn’t check NULL-pointers so there could be NULL-pointer dereference. Is it a bug or am I missing something?

2 Answers 2

The header is mainly used for userspace testing, such as virtio_test .

From the git-log of tools/virtio/virtio_test.c :

This is the userspace part of the tool: it includes a bunch of stubs for linux APIs, somewhat simular to linuxsched. This makes it possible to recompile the ring code in userspace.

A small test example is implemented combining this with vhost_test module.

So yes, the code is a bit unsafe (clean coding would test for a NULL pointer prior to memset() and bail out with an appropriate error message), but since it is just a testing tool, it seems to have been considered uncritical to skip this test.

Yes, that definitely looks like a bug.

The tools/ subdirectory is a collection of user space tools (as the name suggests). You can also see this by the fact that several C standard library headers are included. So this of course is not a kernel bug (that would have been very bad), just a minor oversight in the virtio testing tool.

That virtio testing tool seems to re-define some kernel APIs to mock their behavior in userspace. That function though doesn’t seem to be ever used in practice, just merely defined.

It’s probably meant to be used by someone who wishes to test some virtio kernel code in userspace.

Источник

BUG: kernel NULL pointer dereference

# 9 месяцев, 2 недели назад (отредактировано 9 месяцев, 2 недели назад) имеется арч, i3wm, i5 3330, nvidia gtx 1650, drivers nvidia 460.27
на радостях обновился до беты через АУР.

но во время поигрывания в европку комп просто завис и не реагировал ни на что — даже на alt+ctrl+Fx

после ребута прочел логи и чот я снова думаю чо енто все нвидиа драйвер виновен.
кто нить может объяснить чо там произошло по логам? — то что какая то ошибка связанная с разыменованием нулевого указателя я и так понял из логов. но как она привела к таким последствиям?

safocl
думаю чо енто все нвидиа драйвер виновен…

Ясно одно, что перед ошибкой вызывалась функция/модуль nvidia. Что там произошло конкретно, нужно смотреть дамп падения, а это, считай, не возможно.
Можно еще отметить, что ошибка в user space (ядро не при делах) и что то там не понятное с процессом PID=769, для работы с которым и вызывался модуль nvidia.
Раз получил OOPS, нужно было выжать максимум информации из этого (распределение памяти, список процессов, зависшие процессы), хотя бы мог оцениться, что это за процесс PID=769.

PS — а вообще, рекомендую почитать расшифровку малых дампов OOPS, kernel panic

а на стандартном ядре и на лтс, ошибка тоже появляется?
# 9 месяцев, 2 недели назад (отредактировано 9 месяцев, 2 недели назад) Сначала тоже подумал на ядро (linux-zen), но больше склоняюсь, что к этому имеет отношение supervisor.
При нормальном малом дампе обычно сразу после строки BUG должна идти строка с указанием IP (указатель инструкции в момент неисправности), типа такого (осталось из старых логов)
а у safocl картинка другая
правда никогда не приходилось анализировать с этим supervisor — может оно так и должно быть .
А вообще зачем нужен этот supervisor .

nafanja
а на стандартном ядре и на лтс, ошибка тоже появляется?

# 9 месяцев, 2 недели назад (отредактировано 9 месяцев, 2 недели назад)

safocl
если чесна я ваще не понимаю чо тут имеется ввиду под супервизором.

Разобрался: просто давно не видел дамп OOPS новых cpu …. строчка в логе
говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) — проверить можно по наличию флага в выводе

EDIT 1 — в части

safocl
но склоняюся к ошибке в драйвере нвидии… – все же после обновы его так всутулилося…

vasek
говорит о том, что твой cpu имеет технологию SMAP (Supervisor Mode Access Prevention) — проверить можно по наличию флага в выводе

vasek
А последним выгруженным модулем, согласно логу, и был модуль nvidia.

# 9 месяцев, 2 недели назад (отредактировано 9 месяцев, 2 недели назад)

Вполне возможно, что данный флаг не высвечивается, нужно смотреть полный вывод
cpuid -1 | grep -i SMAP
даже стало интересно — что там у тебя покажет

PS — cpuid в AUR, но если стоит пакет msr-tools, то нужно его удалить

EDIT 1 — не обязательно SMAP, а что то другое, связанное с supervisor, например, SMEP
cpuid -1 | grep -i smep

# 9 месяцев, 2 недели назад (отредактировано 9 месяцев, 2 недели назад) Ну вот, оказался прав. Но по идее должно сработать и grep —color=auto smep /proc/cpuinfo , но cpuid мне нравится больше, хотя это дело вкуса.
Ядро поддерживает эти технологии smap и smep , а если их поддерживает и cpu, то их можно и отключить, используя опции: nosmap, nosmep — отключив тем самым режим supervisor . можешь поэкспериментировать в части изменения быстродействия . ломать тебя вряд ли кто будет.

PS — не исключаю, что этот supervisor имел какое то отношение к OOPS . что то пошло не так с областями памяти kernel и userspace

EDIT 1 — сразу уж добавлю отличие smep от smap — пусть все будет в одном месте

Источник

How do I debug a kernel module in which a NULL pointer appears?

I have a custom kernel module that I compiled from this patch that adds support for the logitech G19 keyboard among other G series devices. I compiled it just fine against Ubuntu’s maverick kernel’s master branch (2.6.35).

I can boot and load the module, but I’m running into a really strange situation. As soon as I load the module (either on boot or through modprobe), I get a black screen and my console locks up.

The weird part is that it doesn’t lock my system up, it’s just the current console session. I can SSH into my box, and it gives me a terminal and a session. And I can type, and I can even run a command and it gives me the output. It then draws my next prompt and immediately locks up.

I see in dmesg that there’s a null pointer, and I get the following stacktrace:

Can anyone point me in the right direction as to how to go about debugging this?

The stacktrace leads me to believe that it’s not the hid-g15 driver but the hid-gfb driver, which creates a frame buffer for the LCD on the keyboard. This makes sense since it’s locking up my display/console but digging into the kernel code isn’t really going anywhere. So much of it is assembly and macro functions.

The last function on the stacktrace that involves my new code is gfb_fb_imageblit . The entirety of that function is

Am I reading the stacktrace wrong? Am I missing something? Any tips on how to debug this?

Источник

Another kernel NULL pointer vulnerability

From:	Tavis Ormandy
To:	full-disclosure-AT-lists.grok.org.uk, bugtraq-AT-securityfocus.com
Subject:	Linux NULL pointer dereference due to incorrect proto_ops initializations
Date:	Thu, 13 Aug 2009 20:57:53 +0200
Message-ID:
Archive-link:	Article, Thread

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 4:33 UTC (Fri) by spender (guest, #23067) [Link]

It works on any vulnerable kernel (I’ve tested extensively here on at least 15 VMs, x86, x64, 2.4, 2.6, with creds, without creds, 4k stacks, 8k stacks).

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 16:30 UTC (Sat) by forcer (guest, #60276) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 17:34 UTC (Sat) by spender (guest, #23067) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 5:29 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 5:36 UTC (Fri) by spender (guest, #23067) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 11:09 UTC (Fri) by jamesmrh (guest, #31622) [Link]

Eric Paris posted on the topic here:

(see comments for further thoughts from Brad).

Note that the LSM and SELinux logic has been reworked upstream by Eric. The primary patch of interest is:

This will allow finer control over the ability to perform low mappings with better separation of DAC and MAC controls & will be pushed to Linus for 2.6.32.

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 17:43 UTC (Fri) by MarkWilliamson (subscriber, #30166) [Link]

I had the impression from previous LWN articles that there was also a bug or, at least, an «unintended feature» in the LSM infrastructure (not specifically SELinux, then), which disabled the normal Linux checking for minimum mmap-able address when an LSM was installed.

So one *aspect* of the problem is affected by the presence of SELinux (or other LSMs), even though SELinux itself may not contain the bug. Is that correct too?

Another kernel NULL pointer vulnerability

Posted Aug 14, 2009 18:00 UTC (Fri) by spender (guest, #23067) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 11:39 UTC (Sat) by trasz (guest, #45786) [Link]

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 9:36 UTC (Sat) by jamesmrh (guest, #31622) [Link]

The SELinux policy in RHEL5 for unconfined domains (i.e. local logged in users) has no check. Eric’s changes will allow the MAC and DAC checks to be properly separated, so SELinux policy can’t override DAC in this case. (See Eric’s blog entry, it has a much more thorough explanation).

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 14:34 UTC (Sat) by jimmybgood (guest, #26142) [Link]

Having patched my kernel to 2.6.30.4 in July, this exploit would not run, with vm reporting that the page couldn’t be mapped.

The problem is that SELinux is too difficult to configure forcing even quite knowledgeable sysadmins to rely on canned distro configurations, which may or may not be suitable for their particular need. In many situations (where WINE was needed), SELinux _was_ doing the right thing.

The same can be said of the hal, console-kit and policykit consortium. I’d feel more comfortable with an X server running as root, than the new unprivileged X, with hal and friends. The only way I can configure hal is to google a magic invocation and cross my fingers. I’ll bet we’ll see major exploits using hal, ck and/or pk coming soon.

I’m not sure what the solution is. My work around is to avoid any security solution that I can’t comfortably configure and feel that I understand fully what I’m doing. That’s never been the case with SELinux. I know there’s a parser that will look at the logs and give you a configuration snippet, but I don’t know how it works and so I don’t trust it.

Another kernel NULL pointer vulnerability

Posted Aug 15, 2009 16:15 UTC (Sat) by nix (subscriber, #2304) [Link]

Источник