Bug 290352 - mdo(1) causes kernel panic in jail
Summary: mdo(1) causes kernel panic in jail
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 15.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Olivier Certner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-18 23:13 UTC by 0x1eef
Modified: 2025-12-08 17:11 UTC (History)
5 users (show)

See Also:
olce: mfc-stable15+
olce: mfc-stable14+


Attachments
Screenshot of the panic (273.21 KB, image/jpeg)
2025-10-18 23:13 UTC, 0x1eef
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description 0x1eef 2025-10-18 23:13:44 UTC
Created attachment 264705 [details]
Screenshot of the panic

## Problem

When I run 'mdo -u user env' in a jail, I observe a kernel panic. 
Screenshot attached.

## Environment

Commit e504946ee119c4bd3940bea798bd47e85b0a25d0

I have configured the host to enable mac_do via /boot/loader.conf:
mac_do_load="YES"

I have configured the jail like so:
cat /etc/jail.conf.d/2.turtle.home.network | grep mac
mac.do.rules = "uid=1001>uid=0,gid=0";

## Reproduction

jexec jail
sysctl security.mac.do.rules='uid=0>any'
mdo -u user env
[panic]
Comment 1 0x1eef 2025-10-19 18:28:05 UTC
I disabled the kern.racct feature - solves the problem.

root@orca:~ # cat /boot/loader.conf | grep racct
kern.racct.enable="0"
Comment 2 Olivier Certner freebsd_committer freebsd_triage 2025-10-19 19:10:03 UTC
This is on HardenedBSD.  Could you try to reproduce this on stock FreeBSD?  This would rule out (or not) the possibility of HardenedBSD-specific modifications from interfering.

I think you provided enough info for me to do it myself, but unfortunately, I'll be off for approx. a week starting now, and without Internet connection, so won't be able to handle this until Monday 27th.

So, if you could in the meantime add more info to this PR, that would be great.  Some other people might be able to look at it during my absence.
Comment 3 0x1eef 2025-10-19 23:56:13 UTC
Sorry. I should have ruled this out as a HardenedBSD-specific bug first, and it looks like that could be the case. I will reopen if it turns out to apply to FreeBSD as well.
Comment 4 Shawn Webb 2025-10-26 23:34:34 UTC
I have been able to reproduce on vanilla FreeBSD 16. Note that the following steps work over ssh, which ends up playing a crucial role in reproducing. This VM uses a default {make,src}.conf

FreeBSD freebsd-01 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n281229-74a6bb524e5b: Fri Oct 17 17:27:53 MDT 2025     shawn@freebsd-01:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

1. ssh into FreeBSD 16 VM
2. sudo jail -c path=/ name=test-01 persist
3. kldload mac_do
4. jexec test-01 /bin/sh

In the jail now:

5. sysctl security.mac.do.rules='uid=0>any'
6. mdo -u shawn id
7. mdo -u shawn /rescue/sh (just exit)
8. mdo -u shawn env /rescue/sh (just exit)

Use ^D to exit the jail and ^D a second time to exit ssh. It's when the ssh process exits that the kernel panics.

savecore 1058 - - reboot after panic: racct_adjust_resource: resource 2 usage < 0                                                                                                    
Oct 26 09:19:38 freebsd-01 savecore[1058]: reboot after panic: racct_adjust_resource: resource 2 usage < 0

Resource 2 is RACCT_STACK.
Comment 5 0x1eef 2025-10-26 23:37:05 UTC
Reopening given the last comment.
Comment 6 Olivier Certner freebsd_committer freebsd_triage 2025-10-28 21:13:56 UTC
(In reply to Shawn Webb from comment #4)

I'm unable to reproduce this panic following your steps on main-n281513-e5f545e0d8, nor with variants where SSH is not involved, or where the initial user on SSH connection is some test user and steps 2 and later are done under an additional 'su -'.

Are you sure the listed steps are exactly what you performed?  E.g., I see a 'sudo' in step 2, which seems superfluous as you must be root to perform 3 and 4.

There must be a difference somewhere.  I've not been using 'sudo' in my tests.  What do you have in '/etc/sysctl.conf'?

Unrelated, but configuration:
sysctl security.mac.do.rules='uid=0>any'
is useless, as root can always change to any user (provided security.bsd.suser_enabled is not 0, which the system does not really support).
Comment 7 Olivier Certner freebsd_committer freebsd_triage 2025-10-29 10:31:57 UTC
(In reply to 0x1eef from comment #0)

I can reproduce your scenario.

(In reply to Shawn Webb from comment #4)

I had forgotten to ensure that RACCT is enabled, that's why I couldn't reproduce it.  But since I can reproduce 0x1eef's scenario and it is smaller, I'll work from there first.
Comment 8 Olivier Certner freebsd_committer freebsd_triage 2025-10-30 17:16:53 UTC
Actually, there is not even a need to create a jail at all for the panic to happen.  Only activating resource accounting is necessary (and launching `mdo` with a different user as a target).

It's due to my forgetting to handle RACCT/RCTL in setcred() (I think I had it in mind at some point; too bad...).  The fix is here: https://reviews.freebsd.org/D53457, and I intend to commit it tomorrow to leave a little time to people to review it if they want.  That fix will appear in 15.0, and will also be backported to stable/14 (and potentially a SA will be issued for 14.3).

Thanks for that report, and congrats to have found a bug in a mdo/mac_do scenario (the actual problem is in fact in setcred(2)) as I have worked hard for this situation not to happen.
Comment 9 commit-hook freebsd_committer freebsd_triage 2025-11-02 18:17:54 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=2be5127c4a31bacac9b4158395bfa844f6033626

commit 2be5127c4a31bacac9b4158395bfa844f6033626
Author:     Olivier Certner <olce@FreeBSD.org>
AuthorDate: 2025-10-29 17:07:59 +0000
Commit:     Olivier Certner <olce@FreeBSD.org>
CommitDate: 2025-11-02 18:15:30 +0000

    setcred(): Fix RACCT resource accounting on credentials change

    When credentials are changed, we need to adjust the sum of resources
    associated to the initial and new process' user IDs (and old and new
    login classes and jails, but setcred() does not change them) for them to
    stay consistent.

    PR:             290352
    MFC after:      3 days
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:  https://reviews.freebsd.org/D53457

 sys/kern/kern_prot.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)
Comment 10 commit-hook freebsd_committer freebsd_triage 2025-11-06 03:38:11 UTC
A commit in branch stable/15 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=2e76660cb71dc113a4f4e0eb05eb190d7fc99e7f

commit 2e76660cb71dc113a4f4e0eb05eb190d7fc99e7f
Author:     Olivier Certner <olce@FreeBSD.org>
AuthorDate: 2025-10-29 17:07:59 +0000
Commit:     Olivier Certner <olce@FreeBSD.org>
CommitDate: 2025-11-06 03:36:33 +0000

    setcred(): Fix RACCT resource accounting on credentials change

    When credentials are changed, we need to adjust the sum of resources
    associated to the initial and new process' user IDs (and old and new
    login classes and jails, but setcred() does not change them) for them to
    stay consistent.

    PR:             290352
    MFC after:      3 days
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:  https://reviews.freebsd.org/D53457

    (cherry picked from commit 2be5127c4a31bacac9b4158395bfa844f6033626)

 sys/kern/kern_prot.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)
Comment 11 commit-hook freebsd_committer freebsd_triage 2025-11-06 23:12:47 UTC
A commit in branch releng/15.0 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=76fb5c23dcca4696d3682bec2dd0e60d81c6db1e

commit 76fb5c23dcca4696d3682bec2dd0e60d81c6db1e
Author:     Olivier Certner <olce@FreeBSD.org>
AuthorDate: 2025-10-29 17:07:59 +0000
Commit:     Colin Percival <cperciva@FreeBSD.org>
CommitDate: 2025-11-06 23:11:10 +0000

    setcred(): Fix RACCT resource accounting on credentials change

    When credentials are changed, we need to adjust the sum of resources
    associated to the initial and new process' user IDs (and old and new
    login classes and jails, but setcred() does not change them) for them to
    stay consistent.

    Approved by:    re (cperciva)
    PR:             290352
    MFC after:      3 days
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:  https://reviews.freebsd.org/D53457

    (cherry picked from commit 2be5127c4a31bacac9b4158395bfa844f6033626)
    (cherry picked from commit 2e76660cb71dc113a4f4e0eb05eb190d7fc99e7f)

 sys/kern/kern_prot.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)
Comment 12 Mark Johnston freebsd_committer freebsd_triage 2025-11-14 16:58:39 UTC
Fixed in 15.0 now.
Comment 13 Mark Johnston freebsd_committer freebsd_triage 2025-11-21 16:22:49 UTC
Do we still need to merge this to stable/14?  The flags indicated so, but I don't see a commit there.
Comment 14 Olivier Certner freebsd_committer freebsd_triage 2025-11-21 16:40:29 UTC
Yes, and we even need a SA/EN. I'm taking care of it.