AMNESIA:33 and FreeBSD TCP/IP stack involvement

2020-12-08 Thread Hartmann, O.
Hello, I've got a question about recently discovered serious vulnerabilities in certain TCP stack implementations, designated as AMNESIA:33 (as far as I could follow the recently made announcements and statements, please see, for instance,

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

2020-12-08 Thread John Kennedy
On Tue, Dec 08, 2020 at 07:10:26PM +0100, Alban Hertroys wrote: > > You didn't say that you've installed the new kernel, which at least starts > > you down the road towards a driver/kernel mismatch. You presumably have a > > non-ZFS boot+root. > > I???m fairly sure I did, actually. > > Last

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

2020-12-08 Thread Bakul Shah
On Dec 8, 2020, at 10:10 AM, Alban Hertroys wrote: > > So I tried again to move to HEAD: > > cd /usr/src > svn up > make buildworld -j12 > make buildkernel -j12 > make installkernel > shutdown -r now > > mount -u / > zpool import -Nf system

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

2020-12-08 Thread Michael Gmelin
On Tue, 8 Dec 2020 19:10:26 +0100 Alban Hertroys wrote: > > On 8 Dec 2020, at 16:40, John Kennedy wrote: > > > > On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote: > >> This seems to have gotten lost in the moderate queue, but after a > >> week I am no closer to a solution, so

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

2020-12-08 Thread Alban Hertroys
> On 8 Dec 2020, at 16:40, John Kennedy wrote: > > On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote: >> This seems to have gotten lost in the moderate queue, but after a week I am >> no closer to a solution, so here???s a resend: >> >> I???ve been trying to get a fresh world

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Mateusz Guzik
On 12/8/20, Mark Johnston wrote: > On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote: >> I think this is a long standing bug against exiting processes. >> >> filedesc_out only increments *hold* count, but that does not prevent >> fdescfree_fds from progressing and freeing everything

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Mark Johnston
On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote: > I think this is a long standing bug against exiting processes. > > filedesc_out only increments *hold* count, but that does not prevent > fdescfree_fds from progressing and freeing everything without any > locks held. I think it is

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Peter Holm
On Tue, Dec 08, 2020 at 10:30:41AM -0500, Mark Johnston wrote: > On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote: > > I just got this panic: > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 9; apic id = 09 > > instruction pointer = 0x20:0x80bc6e22

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Kyle Evans
On Tue, Dec 8, 2020 at 9:48 AM Mark Johnston wrote: > > On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote: > > On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote: > > > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of > > > this, which is supposed to prevent the

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Mark Johnston
On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote: > On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote: > > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of > > this, which is supposed to prevent the table entry from being freed > > since that requires the

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

2020-12-08 Thread John Kennedy
On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote: > This seems to have gotten lost in the moderate queue, but after a week I am > no closer to a solution, so here???s a resend: > > I???ve been trying to get a fresh world running (for the eventual purpose of > running amdgpu

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Mateusz Guzik
I think this is a long standing bug against exiting processes. filedesc_out only increments *hold* count, but that does not prevent fdescfree_fds from progressing and freeing everything without any locks held. A hotfix (for mfc) would add locking around it, but a long term fix should wait for

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Kyle Evans
On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote: > > On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote: > > I just got this panic: > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 9; apic id = 09 > > instruction pointer = 0x20:0x80bc6e22 > >

Re: panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Mark Johnston
On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote: > I just got this panic: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 9; apic id = 09 > instruction pointer = 0x20:0x80bc6e22 > stack pointer = 0x28:0xfe0698887630 > frame pointer

panic: general protection fault from uipc_sockaddr+0x4c

2020-12-08 Thread Peter Holm
I just got this panic: Fatal trap 9: general protection fault while in kernel mode cpuid = 9; apic id = 09 instruction pointer = 0x20:0x80bc6e22 stack pointer = 0x28:0xfe0698887630 frame pointer = 0x28:0xfe06988876b0 code segment = base 0x0, limit 0xf, type