TO give some perspective and show why this doesn't really matters in real world, maximum input length for e.g. To avoid such 'overflow' $Password$ must be smaller than maximum input size supported by the hash function, and $Salt$ must be shorter than maximum input length minus block size of the function. If we assume a very long password and/or salt, then two hash function calls can potentially 'overflow': $H(Password)$ and $H((K_0 \oplus ipad) || Salt)$. If you set your password max length to 100 characters, every password field should allow you to type in at least 101 characters.
Theoretical limit, however, is determined by the hash function used by PBKDF2: under the hood, it uses $HMAC(Password, Salt || Counter)$, which in turn will translates to a series of hash function calls: There's no practical limit to password or salt length you can use with PBKDF2.
