important notice

i wanted to post a message to the qnx4 developer community out there
about a potential problem that they could run into.

if you do the following:

shm_open a memory region
mmap it in

shm_unlink the memory region
*** close the fd for the memory region ***

write to the mmap’d pointer.


if you write to the mmap’d memory after you have already closed the fd that
was used to open the region, and you have also unlinked it then you could
see system problems.

the system problems show themselves as other applications potentially trying
to use the memory that is still ‘owned’ by the process that shm_opened it.
if this memory is given to another process and is used for code, and then
you write to your mmap’d pointer then you could corrupt the code of the
new program.
e.g. sin or some other regular app could fail with a sigsegv or sigill

this will be more formally announced but i felt this was serious enough to
warrant a posting in the conference first as soon as we had seen this.
This problem applies to all versions of Proc425.


Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Do you happen to know if any of the distributed QNX utils or daemons
contain code that produces this chain of events?

rick

PS: I take it that a new fixed Proc will be made available?

Randy Martin wrote:

i wanted to post a message to the qnx4 developer community out there
about a potential problem that they could run into.

if you do the following:

shm_open a memory region
mmap it in

shm_unlink the memory region
*** close the fd for the memory region ***

write to the mmap’d pointer.

if you write to the mmap’d memory after you have already closed the fd that
was used to open the region, and you have also unlinked it then you could
see system problems.

the system problems show themselves as other applications potentially trying
to use the memory that is still ‘owned’ by the process that shm_opened it.
if this memory is given to another process and is used for code, and then
you write to your mmap’d pointer then you could corrupt the code of the
new program.
e.g. sin or some other regular app could fail with a sigsegv or sigill

this will be more formally announced but i felt this was serious enough to
warrant a posting in the conference first as soon as we had seen this.
This problem applies to all versions of Proc425.


Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

this info will be in a more formal response.

the only instance i’ve seen (and how i determined it) was when using memory
contexts in photon and creating and destroying them in very tight loops.

i’ve gone through the other components (like libmalloc and others) and
they all do the right thing… either not close the fd or do an implicit
close when the app exits.

please stay tuned.

Rick Lake <rwlake@spam.redirected.to.dev.null> wrote:

Do you happen to know if any of the distributed QNX utils or daemons
contain code that produces this chain of events?

rick

PS: I take it that a new fixed Proc will be made available?

Randy Martin wrote:

i wanted to post a message to the qnx4 developer community out there
about a potential problem that they could run into.

if you do the following:

shm_open a memory region
mmap it in

shm_unlink the memory region
*** close the fd for the memory region ***

write to the mmap’d pointer.

if you write to the mmap’d memory after you have already closed the fd that
was used to open the region, and you have also unlinked it then you could
see system problems.

the system problems show themselves as other applications potentially trying
to use the memory that is still ‘owned’ by the process that shm_opened it.
if this memory is given to another process and is used for code, and then
you write to your mmap’d pointer then you could corrupt the code of the
new program.
e.g. sin or some other regular app could fail with a sigsegv or sigill

this will be more formally announced but i felt this was serious enough to
warrant a posting in the conference first as soon as we had seen this.
This problem applies to all versions of Proc425.


Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579


Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579