Consider two parties, namely, P_0 and P_1. P_0 and P_1 have plaintexts p_a and p_b respectively.
P_0 encrypts p_a to get c_a = Enc(p_a)
with its public key, and sends it to P_1.
P_1 performs multiply_plain(c_a, p_b, c)
, followed by sub_plain_inplace(c, p_R)
(where p_R is a random plaintext polynomial to hide the product of a and b), and then sends c to P_0.
Can the noise in c reveal some information about p_b to P_0, despite the product being masked by p_R?
If yes, then how can I avoid this leakage? Is there a way to add random noise to c to drown the impact of p_b on noise in c?
Is there a function in SEAL to encrypt using noise from a larger interval? If there is, then maybe I can encrypt p_R with extra noise to drown the impact.
Yes, the noise can in theory reveal information about the inputs to the product, even after adding a fresh encryption to it. Homomorphic encryption schemes are typically not designed to provide input privacy in such MPC protocols. It's not clear to me how feasible this "attack" would be to execute in realistic application scenarios though (except in pathological cases).
To avoid this issue and to obtain semi-honest security for protocols you may want to build from the BFV scheme you can indeed do what you suggested: flood the noise by adding an encryption with artificially large noise. This was used for example here (section 5.2) to prove the security of the protocol. See also Lemma 1 in this paper.
A fancier bootstrapping-based approach is described in this paper by Ducas and Stehle. Since bootstrapping in both BGV and BFV is extremely restrictive (and not implemented in SEAL), I wouldn't consider this approach to be practical except perhaps in some very rare scenarios.