-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ASAN] global-buffer-overflow in std::regex construction #40902
Comments
assign core |
New categories assigned: core @Dr15Jones,@smuzaffar,@makortel you have been requested to review this Pull request/Issue and eventually sign? Thanks |
A new Issue was created by @makortel Matti Kortelainen. @Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
In the core software meeting today it was left unclear if these warnings are a sign of LTO and ASAN being incompatible, or a real problem in the LTO build that ASAN reports. The regex object in question is in cmssw/PhysicsTools/IsolationAlgos/plugins/CandIsolatorFromDeposits.cc Lines 63 to 66 in 3d761d8
|
A quick web search with the stack trace parts led me to this GCC/libstdc++ bug report (data race in |
thanks @makortel for tracking it down? how about using
|
#40915 might fix the ASAN errors |
It would probably be better to use |
There is also other case of the same pattern in cmssw/CommonTools/ParticleFlow/plugins/PFCandIsolatorFromDeposit.cc Lines 77 to 81 in 3d761d8
|
@Dr15Jones ,
if #40915 looks good then I can also take care of #40902 (comment) |
Or shouldn't we just update
weight = cms.double(1), ?
|
#40902 (comment) may be not, there is some logic to use |
In principle it would be straightforward to check if the first character is (alternatively one could ask if supporting leading |
feel free to open a new PR with std::from_char :-) |
Challenge accepted :), see #40956. A potential downside is the larger amount of code. |
Is it possible this is a false positive because of a 'coincidence' of placement of storage of the static object? I.e. could the compiler have placed the string '^[+-]?(\d+.?|\d*.\d*)$' just to the left of a pre-assigned space for the |
I believe ASAN puts guard bytes around static objects. In fact, it tells us that the access is "39 bytes to the left of global variable '*.LC35'", the next static allocation. |
I think this is the implementation looking at the various scan I see lines like which shows that it could have dereferenced the value at _M_end. |
OK, I seem to have gotten a working job. I just put |
Chris' PR is #40984 |
I diffed the assembler output before and after Chris's PR, prior to LTO, and the assembler is identical except for some random stuff in the section names. Whatever is getting changed by that PR is definitely happening at the LTO stage, which is making me somewhat nervous about LTO. |
+core Crash itself was fixed, although @dan131riley's concerns (#40902 (comment)) remain. |
This issue is fully signed and ready to be closed. |
After enabling LTO globally in 13_1_X many workflows in ASAN report
https://cmssdt.cern.ch/SDT/cgi-bin/logreader/el8_amd64_gcc11/CMSSW_13_1_ASAN_X_2023-02-24-2300/pyRelValMatrixLogs/run/1.0_ProdMinBias/step3_ProdMinBias.log#/
The text was updated successfully, but these errors were encountered: