Nmap scan from another PC can trigger kernel-current crash

[e1-531g]

Hello
I am running OpenBSD 5.7 amd64 userland with kernel-current (5.8 amd64). I know this is not supported configuration. On the other hand I discovered that nmap scan (-sO The IP protocol scan) from another PC (Linux kernel based on 3.19, nmap 6.47) triggers remote kernel crash. I think that having mix of userland and kernel from different releases may lead to some problems with applications, but kernel must not crash. So I suppose that properly installed OpenBSD-current can crash too and this is kernel bug. Bug is reproductible for me. Does it reproductible for anyone else?

How to reproduce the problem? From another PC in LAN run:

nmap -sO -O ip_address

My hardware:

lspci -nn | grep -i ethernet
02:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM57785 Gigabit Ethernet PCIe [14e4:16b5] (rev 10)

CPU: Sandy Bridge based Intel Pentium processor

Kernel outputs something like that:

uvm_fault(0xffffffff81905280,0x141,0,1)
kernel: pagefault(trap,code=0)
stopped at mplsip_decap+0x17

[Oko]

Originally Posted by e1-531g

Hello
I am running OpenBSD 5.7 amd64 userland with kernel-current (5.8 amd64). I know this is not supported configuration. So I suppose that properly installed OpenBSD-current can crash too and this is kernel bug. Bug is reproductible for me. Does it reproductible for anyone else?

Are you serious?

[ibara]

Originally Posted by e1-531g

I think that having mix of userland and kernel from different releases may lead to some problems with applications, but kernel must not crash.

This is not guaranteed whatsoever. In fact, I can think of several instances where the kernel would be guaranteed to crash.

Sorry, but you'll have to reproduce this with -current.

[e1-531g]

I come from Linux world, where (in theory) almost everything can crash in userland (except i.e. pid 1) and kernel should continue to run without any problem. I know that kernel without userland probably will not do anything useful, but it should not crash. Ok. Let's assume that thing are different in *BSD world.
I know this is not guaranteed so I didn't send mail to openbsd-bugs.
The thing is I don't want to upgrade to current unless I must. On the other hand I know on this forum there are people who are running -current so maybe somebody could reproduce a problem. It is just a nmap scan from another computer. If somebody will reproduce problem, I will install current and take some steps to report it properly to openbsd-bugs.

[bsd-keith]

Please don't take this the wrong way, but on BSD, the kernel & userland are considered to be one, they are not considered to be separate like in Linux, so you would be much more likely to have problems if you mix & match.

(BSD are operating systems, Linux is a kernel.)

[sacerdos_daemonis]

I come from Linux world

Even with Linux mixing different branches of the same OS will break the system.

I think that having mix of userland and kernel from different releases may lead to some problems with applications, but kernel must not crash. So I suppose that properly installed OpenBSD-current can crash too and this is kernel bug.

Why would you suppose that? If a certain action can crash the system when using the -current kernel with -release, why would the same action crash a -release or -current system that is properly set up?

[kpa]

I don't buy the argument that the kernel should be allowed crash when mixing different versions of userland and kernel. Imagine that a malicious user knows that running 5.7 binaries on 5.8 kernel can be used to crash the system. He can just take a suitable binary from 5.7 and run it from his own home directory and crash the system. This is absolutely not acceptable.

However, I suspect that the real problem in particular case is the cutting edge nature of OpenBSD current and there is a real problem in the kernel that needs to be looked at.

[e1-531g]

@kpa
I think the same.

I have read:
http://undeadly.org/cgi?action=artic...20150730180506
It seems that they were working on pf, especially multiprocessing. So maybe it is just a temporary problem.

[jggimi]

I'm not a member of the OpenBSD Project. I don't speak for them. However, having been a user for many years, I can at least parrot the position of the Project on this particular issue, because it's been discussed before.

"You can run whatever customized 'Frankensystem' monster you want to run. But the Project will only accept problem reports produced by supported configurations. If this problem is not repeatable with -release, -stable, or -current, using the Project-supplied GENERIC or RAMDISK kernel configuration, then it's your problem, and your problem alone."

[ibara]

Originally Posted by kpa

I don't buy the argument that the kernel should be allowed crash when mixing different versions of userland and kernel. Imagine that a malicious user knows that running 5.7 binaries on 5.8 kernel can be used to crash the system. He can just take a suitable binary from 5.7 and run it from his own home directory and crash the system. This is absolutely not acceptable.

You're not thinking in the right direction.

[jggimi]

kpa, e1-531g, here's an informal problem report thread where it was just determined the problem was caused by inadvertently building a Frankensystem.

http://marc.info/?t=143867794900002&r=1&w=2

[kpa]

I hear you and I understand what you mean very well. However, if you have 5.8 kernel and 5.7 userland it's exactly what you get when you're halfway trough an upgrade from 5.7 (using source code method) when you have booted with the new kernel but haven't yet installed 5.8 userland. That should be a supported configuration at least for the purpose of finishing the upgrade if not using it in production. But as I said this is not relevant to the OP's problem because it looks very much like he would observe the same behaviour even if he did have a fully upgraded OpenBSD current on his machine.

[jggimi]

Originally Posted by kpa

...using source code method...

The supported method for upgrading by building from source is to start with the most recently available snapshot.

Is it possible to upgrade without doing so? Of course. It depends upon the starting point, the extent of interface and architectural change to reach the end point, the admin's skills, and the guidance available in the Following -current FAQ.

Using your example, if you start with 5.7-release and build -current from source, you are doing something that is unsupported. As I type this, the oldest snapshot available for any of the supported architectures is for the luna88k, and while that snapshot is six weeks old, it contains more than three months of development over 5.7-release.

...it looks very much like he would observe the same behaviour even if he did have a fully upgraded OpenBSD current on his machine.

That hasn't been shown, yet. As stated earlier in this thread, the problem must be repeatable on a supported configuration before it would be given any attention by the Project, if reported.

Can you replicate the problem?

[e1-531g]

Can you replicate the problem?

I will try on Thursday or Friday to properly install current and then test.
Is this, for example, good source of snapshot?

ht tp ://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/

[ocicat]

Originally Posted by e1-531g

Is this, for example, good source of snapshot?

ht tp ://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/

Yes. A list of sanctioned mirrors can be found at the following:

www.openbsd.org/ftp.html

[denta]

Originally Posted by e1-531g

Hello
I am running OpenBSD 5.7 amd64 userland with kernel-current (5.8 amd64).

Yes, and thus the entire post is meaningless.

[e1-531g]

Hmm. With properly installed current I didn't triggered that crash. Sorry for this thread. I have also educated myself what is page fault.

[betweendayandnight]

Originally Posted by e1-531g

I am running OpenBSD 5.7 amd64 userland with kernel-current (5.8 amd64). I know this is not supported configuration.

Did you mean that if I installed a kernel from /pub/OpenBSD/snapshots/`uname -m`/, I should install packages from /pub/OpenBSD/snapshots/packages/`uanme -m`/ and not from /pub/OpenBSD/5.7/packages/`uname -m`/ ?

[ocicat]

Originally Posted by betweendayandnight

Did you mean that if I installed a kernel from /pub/OpenBSD/snapshots/`uname -m`/, I should install packages from /pub/OpenBSD/snapshots/packages/`uanme -m`/ and not from /pub/OpenBSD/5.7/packages/`uname -m`/ ?

Yes. This is explicitly covered in Section 15.4.1 of the official FAQ. Mixing -release packages with a -current installation of the base system is not supported.

[betweendayandnight]

Originally Posted by ocicat

Yes. This is explicitly covered in Section 15.4.1 of the official FAQ. Mixing -release packages with a -current installation of the base system is not supported.

Sometimes packages in the "snapshots" directory fail to install properly with missing libraries. That's why I installed packages in the "5.7" directory on a "snapshots" kernel.