I prefer to do this kind of thing (communication between a child widget and its parent) using signals and slots. Why? Because if the child depends explicitly on the parent, you end up with a circular dependency, and it's harder to change your design in the future.
The simplest solution is to have Page3 emit an "unlockOk" signal which is connected to a slot in Frame which does the actual "unlocking" of the button. Frame could connect the signal and slot in its constructor, or wherever else it's actually instantiating the Page3 object.
If you want to take it a step further, you could make the signals more generic; for example, signals called "inputValid" (which would be emitted when the password fields match) and "inputInvalid", which would be connected to "unlockOk" and "lockOk" slots. The reason for doing this is that you could re-use the signals in other parts of your application if you need to, and their names clearly indicate what they're communicating.