Your manager doesn't want numbers for the risks.
A manager usually wants to know you won't mess the software up.
The two risk areas amount to "do you know everything you need to know?" and "will you break anything else?"
You should probably give a qualitative analysis of the risks.
List the questions you have -- the mysterious areas -- the things that might require follow-up or that you might break because you don't understand them.
The "numbers" are 1.0. You will have follow-up changes (there are always follow-up changes) and you will introduce new previously unknown bugs (unless you have a really good testing discipline, which sounds unlikely from the situation and the question).
Ideally, you understand the whole problem and won't need follow up. Is this really true? What evidence can you give that you understand everything? If you have evidence, present it and claim that there's no risk of follow-up. If you don't have evidence that you understand the whole problem, list the things you don't understand. That's the risk.
Ideally, you won't break anything else. Is this really true? What evidence can you give that your change is isolated and you won't break anything else? Again, list the things that might break; that's the risk.
Note that perfect knowledge can only come after you've actually completed all the changes. Only after you make the code change, you'll know whether or not you knew everything and didn't break anything else.
Looking into the unknowable future, you can only guess if you know everything and won't break anything.
Consequently, there's a level of diminishing returns. You can provide some evidence that you understand the change and won't break anything, but you can't be absolutely sure of your analysis except by actually making the actual code change.