This is not a problem in itself, but in my opinion a web application should implement the policy that passwords are only input, never output. Following this policy will result in a much more secure system as far as handling passwords is concerned.
If you are going to do this, then make sure you set the appropriate headers to prevent caching in the browser or in any proxy servers en route:
Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0
Note that the password will still be visible if view source is clicked in the user's browser. This is an additional, although very low risk as a normal user is unlikely to do this. The only time I could think the password might "escape" this way is if the user decides to save the page HTML locally using their browser's save page functionality.
You could store the password in session once it has validated against any password requirement policy and matches the confirmation. Then you could simply include some code to suppress output of the password fields if the password has already been accepted by your application. The downside to this approach is that passwords are held in memory for longer than otherwise necessary, which means your application is at a slightly higher risk of memory attacks. Heartbleed was one - of course you need the vulnerability to exist in the first place for the risk of exposure to increase in this way. One way to mitigate this is to hash the password ASAP and store the hash and salt in memory.
If you want to allow the user the option of changing their password, you could output a field with a "magic value" rather than the password itself.
<input type="password" value="notrealpassword">
Then you simply detect whether the user subsequently edits this field to know whether to update the password stored in session.
