[Bug binutils/30951] Null pointer dereference in ldlex.l

[1157401338 at qq dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30951

yuxuan He <1157401338 at qq dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |1157401338 at qq dot com

--- Comment #3 from yuxuan He <1157401338 at qq dot com> ---
(In reply to Nick Clifton from comment #2)
> Hi 时宇羽然 ,
> 
>   Thank you for reporting this problem.  Your analysis is basically correct 
>   and so I have gone ahead and applied a small patch to add a check for
>   YY_CURRENT_BUFFER being NULL.
> 
>   The only problem I had with your analysis is that is shows the contents
>   of the bfin-lex.c file, which is not the one that is built from the
> ld/ldlex.l
>   input file.  I was concerned that there might have been some differences
>   between bfin-lex.c and ldlex.c, differences that affected this problem.
>   But, it turns out that as far as defining YY_CURRENT_BUFFER they are both
>   the same.
> 
> Cheers
>   Nick

(In reply to 时宇羽然 from comment #0)
> Created attachment 15159 [details]
> the detailed information of the bug
> 
> Hi, I found a null pointer dereference bug in the source code of binutils,
> and I have shown the execution sequence below. This bug exists in the file
> /ld/ldlex.l. The white text illustrates the steps that generate the bug.
> The return value of YY_CURRENT_BUFFER can be null, then it dereferenced at
> line 659 without checking if it is null.The detailed instrunctions are in
> the attachment.

(In reply to Nick Clifton from comment #2)
> Hi 时宇羽然 ,
> 
>   Thank you for reporting this problem.  Your analysis is basically correct 
>   and so I have gone ahead and applied a small patch to add a check for
>   YY_CURRENT_BUFFER being NULL.
> 
>   The only problem I had with your analysis is that is shows the contents
>   of the bfin-lex.c file, which is not the one that is built from the
> ld/ldlex.l
>   input file.  I was concerned that there might have been some differences
>   between bfin-lex.c and ldlex.c, differences that affected this problem.
>   But, it turns out that as far as defining YY_CURRENT_BUFFER they are both
>   the same.
> 
> Cheers
>   Nick

you are right, our analysis do not tell where the macro is defined, because
macro is inlined during preprocecing of compile, we actually find the define
via ide l tool, so the file we report may be uncorrect, sorry for that, but
based on the analysis results, the actual macro definition should not differ
significantly, as you said

-- 
You are receiving this mail because:
You are on the CC list for the bug.