AES-CBC-256

FOR ENCRYPTION:

1. We are using HMAC-sha256 for generating "key", which takes "salt", "password".

No, you are using PBKDF2 WITH HMAC-SHA256. That's not at all the same thing as plain HMAC-SHA256. However, the OpenSSL function you identified DOES match this assuming you give it the correct parameters. This also applies to decryption step 1.

1. Padding input data.

Sort of. That padding only works correctly for input data that is up to 16 characters, all of which are ASCII (because you encode it as UTF-8, and any non-ASCII character produces more than one byte, making the encoded value an illegal length). Most longer values will fail, although a few will succeed by bad luck. And even for the values that 'succeed', some will be changed; this is considered bad practice and essentially all competently designed crypto schemes since about 1980 are designed to preserve all data. In particular the very common PKCS5 (sometimes called PKCS7 or PKCS5/PKCS7 for technical reasons) standard padding preserves all data correctly and is already implemented in both Java and OpenSSL, as well as nearly all other decent crypto libraries and devices, and would be a better choice as well as simpler.

With the padding fixed, the Java side could do non-ASCII data, but only if you both encode the plaintext to be encrypted and decode the plaintext after decryption suitably. You have the .getBytes(StandardCharsets.UTF_8) on encrypt, but need to match it with new String(cipher.doFinal(...), StandardCharsets.UTF_8) on decrypt, otherwise it may or may not work depending on the platform and environment you use to run it.

The C side may be harder. OpenSSL is based on old-school C code started before the 1995 and 1999 versions of C started to handle non-English characters, and it understands only bytes, which can be single-byte aka 'narrow' characters. Either you must wrap it with calling code that handles 'wide' characters in a multi-byte encoding such as UTF-8 (and calls the OpenSSL parts using bytes), or you must do this outside the program, by controlling the environment (such as the terminal or emulator) or files. Your question doesn't provide even a hint about any of those, so it's impossible to make any recommendation(s).

Because you treat the 'secret' (password), salt, and IV as Strings, the same considerations apply to them, except that they are likely to come from different source(s) than the data. IV and salt are designed to be byte sequences, and restricting IV in particular to ASCII or even UTF-8 encodings probably reduces security some, but as the topic of SO is programming and not security I won't pursue that. In actual PBKDF2 in PKCS5 password is also octets (Java bytes), but it 'recommends' that text (characters) be encoded as ASCII or UTF-8, and Java does take char[] in PBEKeySpec and encode as UTF-8, so for non-ASCII the OpenSSL caller or environment would need to match that.

Given those limitations: all values are ASCII only, data is not more than 16 chars=bytes and IV is exactly 16, the following C code matches and could interoperate with your Java. Error handling is minimal, and I do both encrypt and decrypt in a single function; you would want to be able to separate them. (corrected)