On 21/06/21(Mon) 23:45, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote:
> > On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> > > Could you annotate which field is being protected by the KERNEL_LOCK()?
> >
> > No. I do not want to invest
On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> > Could you annotate which field is being protected by the KERNEL_LOCK()?
>
> No. I do not want to invest into fine grained crypto locking. I
> need a stable test
On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> > It's not clear to me which field is the KERNEL_LOCK() protecting. Is it
> > the access to `swcr_sessions'? Is it a reference? If so grabbing/releasing
> > the l
On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> It's not clear to me which field is the KERNEL_LOCK() protecting. Is it
> the access to `swcr_sessions'? Is it a reference? If so grabbing/releasing
> the lock might not be enough to fix the use-after-free.
I am running the fix
On 16/06/21(Wed) 22:05, Alexander Bluhm wrote:
> Hi,
>
> I have seen a kernel crash with while forwarding and encrypting
> much traffic through OpenBSD IPsec gateways running iked.
>
> kernel: protection fault trap, code=0
> Stopped at aes_ctr_crypt+0x1e: addb$0x1,0x2e3(%rdi)
>
> dd
ok mvs@
> On 17 Jun 2021, at 01:06, Alexander Bluhm wrote:
>
> On Wed, Jun 16, 2021 at 11:58:48PM +0300, Vitaliy Makkoveev wrote:
>> crypto_getreq() and crypto_freereq() don???t require kernel lock.
>
> Indeed, new diff.
>
> ok?
>
> bluhm
>
> Index: netinet/ip_ah.c
>
On Wed, Jun 16, 2021 at 11:58:48PM +0300, Vitaliy Makkoveev wrote:
> crypto_getreq() and crypto_freereq() don???t require kernel lock.
Indeed, new diff.
ok?
bluhm
Index: netinet/ip_ah.c
===
RCS file: /data/mirror/openbsd/cvs/src/sy
Hi,
crypto_getreq() and crypto_freereq() don’t require kernel lock.
> On 16 Jun 2021, at 23:05, Alexander Bluhm wrote:
>
> Hi,
>
> I have seen a kernel crash with while forwarding and encrypting
> much traffic through OpenBSD IPsec gateways running iked.
>
> kernel: protection fault trap, cod
Hi,
I have seen a kernel crash with while forwarding and encrypting
much traffic through OpenBSD IPsec gateways running iked.
kernel: protection fault trap, code=0
Stopped at aes_ctr_crypt+0x1e: addb$0x1,0x2e3(%rdi)
ddb{2}> trace
aes_ctr_crypt(16367ed4be021a53,8000246e1db0) at a