It is this kind of thing --- the password reset code not expecting ever to be hit from a logged-in session, because it's used in the real world exclusively by people who can't log in --- that create 1/2 the bugs in the real world with password resets. You will find blatant bugs that nobody in the world could possibly miss, except that everyone on the dev team missed them because who tests a password reset from a logged-in account?

"What? Every page gets 'current user' from a common header included in every file that it pulls out of the session, and this page also takes 'email address' from a parameter passed in by the user? OOPS."