It's not quite clear to me what you mean by "outside of [your] code", so if this answer doesn't help, please elaborate. The literal code you have supplied will work, I'm guessing you've reduced it from something that actually fails?
I can think of 2 likely problems in this context:
Allocation Lifetime
Memory for static variables is allocated when the kext is loaded and freed when it is unloaded. Are you sure whatever is using your memory is definitely not using it past the unloading of your kext? If it's an IOKit kext, the kernel will unload it automatically fairly soon after loading unless one of the personalities matches. This might not be what you and your code are expecting.
Threading issues
Essentially all kernel code is multithreaded, and you can't escape it. Static/global variables are particularly vulnerable to race conditions. If one thread is writing to the buffer while another is attempting to read it via printf(), you're asking for trouble. You need to ensure you're serialising access to buffers appropriately, or use a different strategy for managing buffer memory. If the buffers are supposed to be temporary, allocating them on the stack (non-static
within a function) might be a better idea, depending on size. As @Merlin069 mentions, the kernel stack is very small (<16kiB), so avoid anything bigger than maybe a few hundred bytes. The 50 byte buffer in your example should be fine though unless it's a recursive function.
Update:
Regarding your sub-question of "What I have in mind is the difference in memory location between a static variable and one allocated with OSMalloc. Can code within ctl_enqueuedata() access both ?"
Yes.
Accessing memory allocated within the kernel is much like doing so in a regular program. The kernel_task has its own memory map, which is active whenever running in kernel mode. The kernel is monolithic, so a pointer that is valid in one kext is also valid in another. It's only when you want to access user space memory from the kernel, or kernel space from user space, that you have to deal with the mappings explicitly.