Fix address slot overruns causing AMDSupport panics by averycblack · Pull Request #102 · acidanthera/Lilu

averycblack · 2026-01-09T18:03:39Z

EDIT: Should be good to go now

The address slot functionality assumed that the following text would be aligned on page boundaries after the macho header. This isn't the case for kexts though, with AMDSupport in Tahoe only having ~16 bytes of space between the header and first section within the __TEXT segment. Lilu would overwrite __cxx_global_var_init (first function in the __text section of the __TEXT segment) with the patched addresses, causing panics as shown below (Thanks @ParaDoX1994):

[ 70.666538]: Lilu patcher: @ (DBG) newly loaded kext is 0xFFFFFF7FA00B2000 and its name is com.apple.kext.AMDSupport (start func is 0xFFFFFF7FA013E042)
[ 70.666546]: Lilu patcher: @ (DBG) caught the right kext com.apple.kext.AMDSupport at 0xFFFFFF7FA00B2000, invoking handler
[ 70.666555]: Lilu mach: @ (DBG) got nouveau mach-o for com.apple.kext.AMDSupport at 0xFFFFFF7FA00B2000
[ 70.666563]: Lilu mach: @ (DBG) com.apple.kext.AMDSupport has segment is __TEXT from 0xFFFFFF7FA00B2000 to 0xFFFFFF7FA0178000
[ 70.666570]: Lilu mach: @ (DBG) com.apple.kext.AMDSupport has segment is __DATA from 0xFFFFFF7FA0178000 to 0xFFFFFF7FA019D000
[ 70.666577]: Lilu mach: @ (DBG) com.apple.kext.AMDSupport has segment is __DATA_CONST from 0xFFFFFF7FA019D000 to 0xFFFFFF7FA019F000
[ 70.666584]: Lilu mach: @ (DBG) com.apple.kext.AMDSupport has segment is __LINKEDIT from 0xFFFFFF7FA0BF0000 to 0xFFFFFF7FA10B14C9
[ 70.666593]: Lilu mach: @ (DBG) found section __text size 738858 in segment 0
[ 70.666600]: Lilu mach: @ (DBG) found section __const size 17568 in segment 2
[ 70.666608]: Lilu mach: @ Potential slots: 0xFFFFFF7FA00B25F0 - 0xFFFFFF7FA00B25FF : 0xFFFFFF7FA01772A0 - 0xFFFFFF7FA0178000
[ 70.666615]: Lilu mach: @ (DBG) activating slots for com.apple.kext.AMDSupport in 0xFFFFFF7FA01772A0 - 0xFFFFFF7FA0178000

There is two parts to this PR -

Fixing the end bound for address slots. I just grab the first section within the __TEXT segment and use that as the upper boundary for the address slots. This works but I think runs into the issues that were trying to be solved here (in AMDSupport funnily enough)
Finding more free space to use for the addresses as AMDSupport still panics if you use the 14 byte patches. I've tried using the space between the last section and the end of the __TEXT segment ~~but it is currently causing panics on my system and I haven't had a ton of time to debug~~.

This is related to both acidanthera/WhateverGreen#126 and acidanthera/WhateverGreen#124

Offset was giving me nonsensically large values. I wasn't able to find any correlation between slide, kext offset, etc, though the addr field does appear to be accurate. Will need to be tested in older macOS versions (currently tested on Sonoma)

Not really safe as currently written but good enough for testing

Lilu/Sources/kern_mach.cpp

averycblack · 2026-01-10T01:41:32Z

Should be good to go now - turns out the panics were from the load commands being overwritten (probably).
Been tested on Tahoe and Sonoma so far.

vit9696 · 2026-01-10T23:58:14Z

Lilu/Sources/kern_mach.cpp

 	return nullptr;
 }

+kern_return_t MachInfo::kcGetAddressSlots(mach_header_64 *hdr, segment_command_64 *segment) {


This changes things quite heavily for all macOS versions and we support back to 10.4, how far back can we test? If not so much, perhaps more reasonable to provide a guard with getKernelVersion?

Perhaps @Goldfish64 has older macOS versions?

https://github.com/acidanthera/Lilu/blob/master/Lilu/Sources/kern_mach.cpp#L934
My understanding is that this should only affect Big Sur+. I made sure to not touch what I thought was the Prelinked kernel implementation here

Totally down to older versions, I think I got a big sur installer somewhere I could boot pretty quickly as a test. M4700 has 10.8 as well if we need a PK test.

I do have reasonable suspicion that the sections are not page aligned in older versions. Taking a look at 10.13 and 10.8 now. Would it be worth extending this fix to those versions as well? It would increase the test surface pretty substantially.

Could do, but really need to test. I have VMs with older versions, but I almost do not use kexts there.

QiuChenly · 2026-01-13T05:46:02Z

The issue has been confirmed to be caused by an out-of-bounds write. I tested on my Hackintosh with macOS 26.2 (25C56) and can confirm the fix works.
Since Lilu needs to support older macOS versions, it might be helpful to add a check for whether the Segment space in AMDSupport is sufficient, so the appropriate strategy can be selected accordingly.
Thanks to @averycblack for the commit and @vit9696 for the contribution.

averycblack · 2026-01-14T05:07:00Z

Tested relatively quickly on macOS versions 10.8, 10.13, 10.15, and 11. Didn't look at the logs too closely but I didn't see anything strange with the addresses printed and Whatevergreen, AppleALC, AiportBrcmFixup, etc all appeared to be working as far back as 10.8.
Excerpt from High Sierra:

Lilu   patcher: @ (DBG) invoked at kext loading
Lilu   patcher: @ (DBG) processing already loaded kexts by iterating over all kmods
Lilu   patcher: @ (DBG) caught the right kext com.apple.driver.AppleACPIEC at 0xFFFFFF7F8EFBF000, invoking handler
Lilu      mach: @ (DBG) Potential slots: 0xFFFFFF7F8EFBF458 - 0xFFFFFF7F8EFBF50C : 0xFFFFFF7F8EFC3FFF - 0xFFFFFF7F8EFC4000
Lilu      mach: @ (DBG) activating slots for com.apple.driver.AppleACPIEC in 0xFFFFFF7F8EFBF458 - 0xFFFFFF7F8EFBF50C
Lilu      mach: @ (DBG) aslr/load slide is 0xffffff7f8efbf000
Lilu      mach: @ (DBG) getRunningPosition 0xffffff7f8efbf000 of memory 40960 size
Lilu      mach: @ (DBG) found symbol __ZN11AppleACPIEC14ecSpaceHandlerEjmjPmPvS1_ at 0xffffff7f8efc0244 (non-aslr 0x1244), type f, sect 1, desc 0
Lilu   patcher: @ (DBG) from 0xFFFFFF7F8EFC0244 to 0xFFFFFF7F92A1A7D6 diff 0x0000000003A5A58D argument 3A5A58D
Lilu   patcher: @ (DBG) from 0xFFFFFF7F926B9D31 to 0xFFFFFF7F8EFC024A diff 0xFFFFFFFFFC906514 argument FC906514
Lilu   patcher: @ (DBG) wrapped __ZN11AppleACPIEC14ecSpaceHandlerEjmjPmPvS1_

This is still limited to x86_64 builds so theoretically we should just need tests on 10.6 and/or 10.7 I think. I don't have any machines that could realistically test those versions unfortunately.

averycblack · 2026-01-18T20:47:29Z

@vit9696 I see a couple paths forward - I'll leave it up to you as to what you want to do:

Revert c325a54 and merge, having tested Big Sur, Sonoma, and Tahoe. This would mean that the new changes only affect macOS 11+.
Leave it as is and try to get tests for 10.6/7.
Merge the PR as is, calling a 10.8 test good enough.

It sounds like @Goldfish64 does not have any machines running 10.6/7. I do not either - a VM test is probably the best we will get with these older versions.

vit9696 · 2026-01-19T05:28:24Z

I tested both macOS 10.6.8 and macOS 10.7.5 in a VM with ATI Radeon HD 6450 GPU. I can confirm that VSMC and WEG load fine there. I can also confirm that patching getProperty in XNU by WEG works with the new Lilu. I do not think there is anything to patch kext-wise, because in both 10.6 and 10.7 AMDRadeonX3000.kext was ATIRadeonX3000.kext, so WEG did not know about it.

I think this patch should be safe to merge. Could you handle that please? Will need to update the changelog and release planning.

averycblack · 2026-01-19T05:32:05Z

Will do

luchina-gabriel · 2026-01-29T21:54:27Z

Excellent!!!

I tested it here with macOS Tahoe 26.2 using various setups, and one in particular using an RX 6900 XT (Device ID 73AF, which requires FakeID for 73BF) and the installation worked perfectly, no longer needing to temporarily disable WhateverGreen during the macOS Tahoe installation.

Another thing I noticed that solved the problem was installing macOS Tahoe 26.2 with the AMFIPass.kext (1.4.1) kext and the set of 3 kexts to activate BCM94360 (IO80211FamilyLegacy.kext, IOSkywalkFamily.kext and AirPortBrcmNIC.kext) also enabled.

averycblack added 6 commits January 1, 2026 17:26

Fix print statements in findSectionBounds

a2abb19

Use __TEXT __text section as address slot upper bound

e683a01

Account for header size in addition to load commands

f128e5a

Try using section after __TEXT:__const for address slots

3ac6ead

Not really safe as currently written but good enough for testing

Break out address slots into separate function

5ebf813

averycblack commented Jan 9, 2026

View reviewed changes

Lilu/Sources/kern_mach.cpp Outdated Show resolved Hide resolved

averycblack commented Jan 9, 2026

View reviewed changes

Lilu/Sources/kern_mach.cpp Outdated Show resolved Hide resolved

averycblack added 2 commits January 9, 2026 12:05

Revert findSectionBounds pointer change

eb1ee88

Fix start address after mach headers

1156dd1

averycblack marked this pull request as ready for review January 10, 2026 01:41

vit9696 reviewed Jan 10, 2026

View reviewed changes

QiuChenly mentioned this pull request Jan 13, 2026

Fix sticking at KernelCache validating on Tahoe acidanthera/WhateverGreen#126

Closed

Use section info for prelinked kernel

c325a54

Changelog

d3f5e0c

averycblack merged commit e4748cc into acidanthera:master Jan 19, 2026
3 checks passed

averycblack deleted the averyb/fix-address-slot-overruns branch January 19, 2026 05:45

Conversation

averycblack commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

averycblack commented Jan 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vit9696 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

vit9696 Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

averycblack Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

averycblack Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

vit9696 Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

QiuChenly commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

averycblack commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

averycblack commented Jan 18, 2026

Uh oh!

vit9696 commented Jan 19, 2026

Uh oh!

averycblack commented Jan 19, 2026

Uh oh!

Uh oh!

luchina-gabriel commented Jan 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

averycblack commented Jan 9, 2026 •

edited

Loading

averycblack commented Jan 10, 2026 •

edited

Loading

QiuChenly commented Jan 13, 2026 •

edited

Loading

averycblack commented Jan 14, 2026 •

edited

Loading