That doesn't matter - if the exploit "allows kernel-level access" then the HBMenu itself would run at kernel level.
My guess is that Cubic Ninja developers simply f*cked up, which does happen quite often, and allocated more memory than they would ever possibly need, leaving plenty of space for your own binary. Of course this is all speculation, I don't dabble in this sort of thing.
The exploit in and out of itself does nothing - it just overflows memory to push custom code into executable space. You're free to speculate though.
I think it's just genuine curiosity, which is fine. People naturally want a full-blown CFW with total control of the system - that's always the ultimate goal. They're free to investigate, too - curiosity is the mother of all CFW's, much like necessity is the mother of invention.
that the problem imho. We dont know how far the exploits goes. For all we know it could install a silent programm with kernel rights that manages the HBmenu instaltion.
Once again, you're exploiting a userland application, so all you're going to get is userland privileges of that application - that's how the protection works. Executables allowing for kernel-level access have allocated space, they belong to the OS, you would have to exploit them to gain higher access. In some cases there is an area of opportunity or some overlap there, but that's a one in a million case. This is why mset worked and there's a 99% chance that this does not.
and what if this is such a case? Smealum said afterall that the devs tried to close one exploits but opened and even bigger one. My point still is without the source we wont know for sure.
Granted.
Also, little point in quoting me - I'm no hacker, I just post educated opinions. 
Xdqwerty
@
Sicklyboy:
@
Sicklyboy:
