## Description of problem: There is an off-by-one boundary check in `gnutls_pkcs12_bag_set_data()` which can lead to a heap out-of-bounds write when a PKCS#12 bag already contains the maximum number of elements. The internal PKCS#12 bag structure stores bag elements in a fixed-size array of `MAX_BAG_ELEMENTS` entries. In the current code, the setter rejects insertion only when: ```c bag->bag_elements == MAX_BAG_ELEMENTS - 1 ``` This means the function rejects a bag containing 31 elements, but does not reject a bag containing 32 elements. At the same time, PKCS#12 parsing can legitimately create a bag with `bag_elements == 32`, because the decode path sets: ```c bag->bag_elements = MIN(MAX_BAG_ELEMENTS, count); ``` So a PKCS#12 file containing 32 or more bag entries produces a parsed bag in a full-capacity state. If an application then calls `gnutls_pkcs12_bag_set_data()` or one of its wrappers such as: * `gnutls_pkcs12_bag_set_crt()` * `gnutls_pkcs12_bag_set_crl()` * `gnutls_pkcs12_bag_set_key()` the off-by-one check does not trigger, and the function writes to `bag->element[32]`, which is one element past the end of the 32-element array. This is not based on a forged internal structure or an invalid caller-created object. The full bag state is produced by the library itself through the normal PKCS#12 parsing path, and the subsequent append call is a normal public API operation that should fail safely instead of writing out of bounds. ## Version of gnutls used: 3.8.12-73-g8b6731064-dirty ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Not distributor-specific in this report. ## How reproducible: Steps to Reproduce: * Create or obtain a PKCS#12 structure whose SafeContents contains at least 32 bag entries. * Import the PKCS#12 and retrieve the bag through the normal PKCS#12 parsing APIs, so the resulting bag reaches `bag_elements == 32`. * Call `gnutls_pkcs12_bag_set_crt()`, `gnutls_pkcs12_bag_set_crl()`, `gnutls_pkcs12_bag_set_key()`, or `gnutls_pkcs12_bag_set_data()` to append one more element to that parsed bag. ## Actual results: The append path does not reject the full bag state created by parsing. Instead, it writes a new element at index `32`, which is out of bounds for the fixed 32-element array. This causes heap memory corruption. ## Expected results: When the bag already contains `MAX_BAG_ELEMENTS` entries, the append path should reject the operation and return an error without writing outside the allocated array. The boundary check should reject any case where: ```c bag->bag_elements >= MAX_BAG_ELEMENTS ```