TLDR: As long as the network connection to the DB is secure, and as long as salted hashes are stored in your tables, calling a stored procedure with a plaintext password is fine. I think your time and effort is better spent protecting the database from unauthorized access of the kind that makes it possible to obtain a trace of stored procedure calls.
First, I understand the scenario in question to be that an attacker may recover the plaintext password by reviewing parameter values passed to the stored procedure, one of which is the plaintext password, and then use that password to compromise a user account in your application.
If that is correct, then the only purely technical solution I see is to implement a PK scheme within the scope of the stored procedure, so that the password must be encrypted with the stored procedure's public key, the ciphertext passed into the stored procedure, and the parameter value then decrypted by the stored proc itself with a private key before being used. (Or better, like TLS itself, you could negotiate a Diffie-Hellman exchange using other stored procs, and use a session key.) Unless you can find some open-source implementation of this out there, that you trust, and use it, this will be a very heavy lift. And you have to protect that private key now.
But consider what you are really trying to protect yourself from. In this scenario, the attacker can read your stored procedure calls and obtain the values passed in. Would any user with this privilege also have read access to whatever private key you use, or select/insert/update access to your tables? If so, then even if you go through the labor of implementing PKI at the stored procedure level, your efforts are instantly defeated.
Also let me respond specifically to the idea of hashing the password, with a salt of course, and passing in the hashed value to the stored procedure. If you do this, then the hashed value is now the password. All an attacker has to do, if he really can read your stored proc parameters, is repeat back those parameters exactly as he sees them to compromise the system. He doesn't actually need to reverse the hash and learn what the "plain" password is; the hashed value is the plaintext password now. So this scheme has no effect.