Oracle Linux 6 update 9
By WimCoekaerts-Oracle on Mar 28, 2017
One thing we discovered during testing of OL6.9 was that a recent change in "upstream" glibc can cause memory corruption resulting in a database start-up failure every now and then.
Since we caught this prior to release, we have, of course, fixed the bug.
The following code change introduced the bug (glibc-rh1012343.patch)
char newmode[modelen + 2]; - memcpy (mempcpy (newmode, mode, modelen), "c", 2); + memcpy (mempcpy (newmode, mode, modelen), "ce", 2); FILE *result = fopen (file, newmode);
As you can see, someone added e to newmode (c to ce) but forgot to increase the size of newmode (2 to 3) so there is no null character at the end.
The correct patch that we have in glibc as part of OL6.9 is:
- char newmode[modelen + 2]; - memcpy (mempcpy (newmode, mode, modelen), "ce", 2); + char newmode[modelen + 3]; + memcpy (mempcpy (newmode, mode, modelen), "ce", 3);
The Oracle bug id is 25609196. The patch for this is in the glibc src rpm. The customer symptom would be a failed start of the database because of fopen() failing.
Something like this:
Wed Mar 22 *17:19:51* 2017 *ORA-00210: cannot open the specified control file* ORA-00202: control file: '/opt/oracle/oltest/.srchome/single-database/nas/220.127.116.11.0-8192-72G/control_0 01' ORA-27054: NFS file system where the file is created or resides is not mounted with correct options *Linux-x86_64 Error: 13: Permission denied* Additional information: 2 ORA-205 signalled during: ALTER DATABASE MOUNT... Shutting down instance (abort)