AppArmor oops when loading an empty profile

The apparmor.d(5) manpage technically does say that an APPARMOR_PROFILE consists of nonempty statements. However, AppArmor will rudely enforce this by oopsing the kernel. This is confirmed on a Lucid 2.6.32-8 kernel checked out from its git repo. I have not confirmed this on other kernels yet.

TEST CASES:

(1) Note apparmor_parser validates this profile:
[jdong@hideout:/tmp]$ sudo apparmor_parser -d
apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
profile boom {}

^D
----- Debugging built structures -----
Name: boom
Profile Mode: Enforce
Capabilities:
[jdong@hideout:/tmp]$ echo $?
0

(2) Now, try to load this profile into the kernel

[jdong@hideout:/tmp]$ sudo apparmor_parser --add -K
apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
profile boom {}
[1] 6003 killed sudo apparmor_parser --add -K

(3) Looking in dmesg:

[184066.515809] BUG: unable to handle kernel NULL pointer dereference at (null)
[184066.515817] IP: [<ffffffff8125ee7d>] aa_unpack+0xdd/0x2d0
[184066.515867] PGD 5c974067 PUD 35d9d067 PMD 0
[184066.515872] Oops: 0000 [#7] SMP
[184066.515876] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD/online
[184066.515885] CPU 0
[184066.515891] Modules linked in: vmblock vmmemctl vmhgfs pvscsi isofs udf crc_itu_t acpiphp binfmt_misc sha256_generic cryptd aes_x86_64 aes_generic dm_crypt snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ppdev lp iptable_filter parport_pc snd soundcore ip_tables x_tables snd_page_alloc psmouse serio_raw parport i2c_piix4 shpchp btrfs zlib_deflate crc32c libcrc32c floppy e1000 mptspi mptscsih mptbase scsi_transport_spi intel_agp
[184066.515940] Pid: 6003, comm: apparmor_parser Tainted: G D 2.6.32-8-generic #11 VMware Virtual Platform
[184066.515943] RIP: 0010:[<ffffffff8125ee7d>] [<ffffffff8125ee7d>] aa_unpack+0xdd/0x2d0
[184066.515948] RSP: 0018:ffff88001d4d5e18 EFLAGS: 00010202
[184066.515951] RAX: ffff880000496000 RBX: ffff88001d4d5e58 RCX: ffff880038c5125c
[184066.515953] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88001d4d5e18
[184066.515956] RBP: ffff88001d4d5e48 R08: 0000000000000000 R09: 0000000000000000
[184066.515958] R10: 0000000000000001 R11: 0000000000000002 R12: ffff88001d4d5e18
[184066.515961] R13: ffff88001d4d5f48 R14: 0000000000000001 R15: 0000000000000000
[184066.515981] FS: 00007f35567d8700(0000) GS:ffff880001c00000(0000) knlGS:0000000000000000
[184066.515985] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[184066.515987] CR2: 0000000000000000 CR3: 000000004bce9000 CR4: 00000000000006f0
[184066.516023] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[184066.516047] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[184066.516051] Process apparmor_parser (pid: 6003, threadinfo ffff88001d4d4000, task ffff880042a62ac0)
[184066.516103] Stack:
[184066.516105] ffff880038c51200 ffff880038c51273 ffff880038c51273 0000000000000005
[184066.516109] <0> ffff88001d4d5e58 0000000000000073 ffff88001d4d5ec8 ffffffff8125dffb
[184066.516114] <0> 0000000000000000 0000000000000020 ffffffff81710bfb 0000000000000000
[184066.516119] Call Trace:
[184066.516124] [<ffffffff8125dffb>] aa_interface_add_profiles+0xcb/0x1d0
[184066.516134] [<ffffffff81037499>] ? default_spin_lock_flags+0x9/0x10
[184066.516139] [<ffffffff8125a2ec>] aa_profile_load+0x3c/0x60
[184066.516146] [<ffffffff81127008>] vfs_write+0xb8/0x1a0
[184066.516152] [<ffffffff81548794>] ? do_page_fault+0x194/0x370
[184066.516156] [<ffffffff81127aac>] sys_write+0x4c/0x80
[184066.516163] [<ffffffff81012002>] system_call_fastpath+0x16/0x1b
[184066.516166] Code: 4c 89 e7 e8 46 fb ff ff 48 3d 00 f0 ff ff 0f 87 f2 01 00 00 44 8b 15 77 c2 58 00 45 85 d2 74 8d 48 8b 50 78 44 8b 88 80 00 00 00 <48> 8b 3a 44 8b 57 08 45 85 d2 0f 84 72 ff ff ff 48 83 c7 0c 45
[184066.516202] RIP [<ffffffff8125ee7d>] aa_unpack+0xdd/0x2d0
[184066.516206] RSP <ffff88001d4d5e18>
[184066.516208] CR2: 0000000000000000
[184066.516211] ---[ end trace c18b1f57d3da0166 ]---

On the bright side, the only effect seems to be a SIGKILL'ed apparmor_parser -- the kernel doesn't appear to be wedged in anyway after the fact. Still -- either apparmor_parser should refuse to load such a profile, or the kernel should handle this a lot more gracefully!