Re: [PATCH 3/6] disk: part_mac: Fix stack corruption on devices with large blocks

On Tue, Aug 25, 2026 at 09:37:43PM +0200, Heinrich Schuchardt wrote:
> On 7/31/26 14:40, Alexey Charkov wrote:
> > part_test_mac(), part_print_mac() and part_get_info_mac() each declare a
> > single-block buffer sized after the descriptor struct:
> > 
> > 	ALLOC_CACHE_ALIGN_BUFFER(mac_driver_desc_t, ddesc, 1);
> > 	ALLOC_CACHE_ALIGN_BUFFER(mac_partition_t, mpart, 1);
> > 
> > Both structs are 512 bytes, but every blk_dread() below them asks for one
> > block, which transfers desc->blksz bytes. On a device with 4096-byte
> > logical blocks that writes 4096 bytes into a 512-byte on-stack buffer and
> > corrupts the stack.
> > 
> > part_test_mac() runs on every block device during partition probing, so on
> > sandbox with CONFIG_MAC_PARTITION=y this crashes on any access at all to a
> > device with large blocks, for instance:
> > 
> > 	host bind 0 disk.img 4096
> > 	part list host 0
> > 
> > Pad the buffers out to the block size with ALLOC_CACHE_ALIGN_BUFFER_PAD(),
> > which is what part_efi.c already does for its own block buffers.
> > 
> > Signed-off-by: Alexey Charkov <[email protected]>
> 
> Modern Apple Computers use GPT partition tables.
> 
> Gemini claims:
> 
> Because APM was functionally obsolete by the time Advanced Format (4Kn)
> drives emerged in the 2010s, Apple never updated the specification to
> establish official compatibility guidelines for native 4 KiB sectors.
> 
> If Apple has not defined how to treat 4 KiB sectors, we should not try to
> invent a scheme.
> 
> Apple has already deleted the documentation of this outdated partition table
> format (http://developer.apple.com/techpubs/mac/Devices/Devices-126.html)
> 
> My preference would be to remove this driver completely.

Yes, this is another case where we can just drop the driver and if
someone *needs* this for something, likely emulated, they can bring it
back.

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCao3w1QAKCRAr4qD1Cr/k
CqZOAP9MGw7/ykK1xvnrejdbZa14qZsLnTnbDKF3hR9JoTG/yAD/dEgF6Maiisjg
0Z7gRom9kOTZ5anNHE6pkEUBdsgVwQ0=
=NCyH
-----END PGP SIGNATURE-----