Re: Secure Dereference of NULL-Pointer when using list.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Ricard,

Thank you for your answer. My problem was my incorrect (?) understanding of "s->foo". I thought it being equivalent to "(*s).foo" rather than a direct offset calculation.

Do you have any references for me? I could not find anything in the ANSI-C standard.

Regards,

Hendrik

Ricard Wanderlof wrote:
On Wed, 4 Oct 2006, Hendrik Post wrote:


While studying the Infiniband drivers if found an interesting line of code within the preprocessed files from kernel 2.6.14.1:

// 85 "drivers/infiniband/core/mad.c"
entry = (struct ib_mad_port_private *) ((char *)__mptr - (unsigned int) (&((struct ib_mad_port_private *)0) ->port_list) );

This line is the result of a macro expansion from list.h. I wonder why it is safe to dereference the NULL-pointer in the second part of the right side:

(& ((struct ib_mad_port_private *)0) ->port_list) )

The NULL is never dereferenced. (Note that -> has higher priority than &).

I.e. you take the address of

((struct ib_mad_port_private *)0) ->port_list

which is simply the offset of port_list in the struct. The 0 is never deferenced, because the (supposed) value at port_list is never used, only its address.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux