I never encountered a gimbal lock using this method, even for axis unlocked rotations (3d free roaming movement) and it is still my favored way to go about these things.
Gimbal lock is only an issue with parameterised orientations, like euler angles. eg,
assume forward vector is (0,0,1) and up vector is (0,1,0), then you can define any orientation with three successive transforms, parameterised by three angles:
set camera roll/banking angle - rotate about vector (0,0,1)
set camera pitch/elevation angle - rotate about vector (1,0,0)
set camera bearing/azimuthal angle - rotate about vector (0,1,0)
But if elevation angle were at 90 degrees, then the bearing and roll transformations become identical. So in effect, you lose one of your three parameters when elevation=90. That is gimbal lock.
The system you are using weezl is relatively stable, although if the up and forward vectors are rotated, you have to make sure they (i) remain unit vectors, and (ii) remain orthogonal, otherwise they are liable to drift over time. This can be achieved with a combination of dot and cross products.
The only other thing to watch out for is getting a zero vector at some point in your transformations (which could destroy your whole orientation frame if you later cross product it again with your axes).