I think your PR has pulled in several other changes that are unnecessary or incorrect. I would start again with a clean branch of the current Arduino_STM32 repo, and apply only the changes needed for CAN.
It seems some changes in USB are inevitable, because in the F1 the USB shares an ISR and other things with CAN. According to the comments in the PR, USB cannot run at the same time as CAN, but I'm not sure that is true in general. I think it is possible to run both USB and CAN but it may take some careful coding.
Edit; I quickly skimmed the thread and the shared buffer was mentioned at the start. The quote from the reference manual is (RM0008, pg.655)
I think ST are being disingenuous here. The nature of comms is that you create a connection, then unsolicited data can arrive any time. ST seem to be suggested that you do some USB for a bit, then close it, do some CAN, close it, re-enumerate the USB and do some USB. I suppose in theory if you control the protocol on USB and CAN you could arrange for a strict ping-pong controlled by the F103, but that is a very special case and not practical.Note: In low, medium-, high- and XL-density devices the USB and CAN share a dedicated 512-
byte SRAM memory for data transmission and reception, and so they cannot be used
concurrently (the shared SRAM is accessed through CAN and USB exclusively). The USB
and CAN can be used in the same application but not at the same time.
I think practically speaking, USB and CAN can not be used in the same application on F103. Certainly in our Arduino case, we try to present an easy to use API for the user. I can't think of a sensible way to prevent users trying to use USB and CAN concurrently. Any run time co-existence is going to tie USB and CAN fundamentally together, and generating a run time error is quite confusing for unsuspecting users.
So I'm not sure how to proceed with this. USB is pretty baked in to the Arduino_STM32 core. Enabling CAN means disabling USB, so operation of USB code becomes moot after that. I think the best we could do is minimise changes to USB, and as long as the user does not enable CAN those changes have no impact. The least change is to call a CAN interrupt hook in the USB interrupt, CAN without interrupts is pretty useless.