Re: git: 9d18115ca0ab - main - sound: Retire snd_mtx* wrappers

From: Shawn Webb <shawn.webb_at_hardenedbsd.org>
Date: Fri, 21 Nov 2025 23:54:09 UTC
On Sat, Nov 22, 2025 at 12:50:19AM +0100, Christos Margiolis wrote:
> On Fri Nov 21, 2025 at 9:46 PM CET, Shawn Webb wrote:
> > On Fri, Nov 21, 2025 at 08:45:27PM +0000, Shawn Webb wrote:
> >> On Fri, Nov 21, 2025 at 04:15:03PM +0000, Christos Margiolis wrote:
> >> > The branch main has been updated by christos:
> >> > 
> >> > URL: https://cgit.FreeBSD.org/src/commit/?id=9d18115ca0ab0ef3f34173d4e2bdabec916d0b60
> >> > 
> >> > commit 9d18115ca0ab0ef3f34173d4e2bdabec916d0b60
> >> > Author:     Christos Margiolis <christos@FreeBSD.org>
> >> > AuthorDate: 2025-11-21 16:14:33 +0000
> >> > Commit:     Christos Margiolis <christos@FreeBSD.org>
> >> > CommitDate: 2025-11-21 16:14:47 +0000
> >> > 
> >> >     sound: Retire snd_mtx* wrappers
> >> >     
> >> >     Do not create mutexes with snd_mtxcreate(). It doesn't provide any
> >> >     value, plus it first allocates the mutex with malloc(9). Allocate
> >> >     mutexes in the stack and use mtx_* functions directly instead of the
> >> >     snd_mtx* wrappers.
> >> >     
> >> >     Sponsored by:   The FreeBSD Foundation
> >> >     MFC after:      1 week
> >> >     Reviewed by:    kib, markj
> >> >     Differential Revision:  https://reviews.freebsd.org/D53855
> >> 
> >> Hey Christos,
> >> 
> >> I'm getting the following error on buildkernel:
> >> 
> >> ==== BEGIN LOG ====
> >> /usr/src/sys/dev/sound/pci/hdspe-pcm.c:726:3: error: call to undeclared function 'snd_mtxunlock'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration]
> >>   726 |                 snd_mtxunlock(sc->lock);
> >>       |                 ^
> >> 1 error generated.
> >> --- hdspe-pcm.o ---
> >> ==== END LOG ====
> >
> > Never mind. I didn't realize HardenedBSD had a change to that file.
> > Sorry for the noise!
> 
> So all good? Out of curiousity, what change is there on HardenedBSD?

Yeah, all good. There's a potential NULL pointer dereference due to a
lack of a return value check from malloc(..., M_NOWAIT). I haven't
done any determination as to whether the bug is triggerable, but it
exists nonetheless.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username:  shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc