We have observed a fairly severe issue after Bare Metal ODA patching from the bundle 18.104.22.168.0 to the bundle 22.214.171.124.0 (the latest available among the 12.1 bundles at the time of this writing)
Namely - none of the 126.96.36.199 databases would start as soon as Infrastructure & GI components of the ODA were patched via the "oakcli update -patch 188.8.131.52.0 -server" command.
Error messages were indicating that DB control file could not be identified.
We were still able to see each 184.108.40.206 DB's control file via the asmcmd>lsdg exactly where it was expected to be.
At the same time either on CRS restart or after the "srvctl start instance" command the DB instance would show up in the "ps -ef | grep pmon" output for a few moments and then it would disappear.
After looking into the DB alert files the following error messages were spotted for the times when the attempts to start 220.127.116.11 databases were made.
ORA-600 [kfdJoin3]   
Also. luckily enough, this MOS DocID has been posted in mid-February 2018 and it describes the same exact issue ... and the solution !
Database Instance Will Not Start ORA-600 [kfdJoin3]    After Patch 18.104.22.168.0 Including the ODA (Doc ID 2341707.1)
The solution came down to completing ODA patching up to and including the RDBMS homes and then downloading the one-off patch p18948177_112040_Linux-x86-64.zip that simply needed to be applied per its README.
It is important to note that this one-off patch should NOT be applied to the GI homes on the ODA since those homes would be already at 12.1 and this one-off patch is specific to 22.214.171.124 homes.
Once we applied the patch, via opatch apply, all 126.96.36.199 databases had started as expected.
Hope this article could help if you end up being in the situation that we had found ourselves after applying ODA bundle patch 188.8.131.52.0 to the appliance where databases 184.108.40.206 are still running.