Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Thu, 11 Mar 2021 23:38:53 -0000

Public bug reported:

The recSup.h typed_rset get_enum_str() method has this prototype:

    long (*get_enum_str)(const struct dbAddr *paddr, char *pbuffer);

The method gets no indication how large pbuffer is, so it's easy for it
to overflow it, although not by much.

The bi and bo records both hope it's one byte longer than their
associated ZNAM/ONAM fields (which are 26 bytes long) because they call
strncpy(pbuffer,,26) and then write a nil byte to pbuffer[26].

The mbbi and mbbo records at least don't overflow the buffer they assume
is 26 bytes long since they don't bother writing the nil byte after
calling strncpy(pbuffer,,26).

No other record types in Base define this method, which isn't trivial to
get called. I think this database should be doing it when lsi gets
processed, although valgrind doesn't seem to notice the overflow:

record(bi, bi) {
  field(ZNAM, "26-character-enum-string.")
}
record(lsi, "lsi") {
  field(SIZV, 16)  # This is the minimum that lsi actually uses.
  field(INP, "bi")
}

** Affects: epics-base
     Importance: Medium
         Status: Triaged

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1918762

Title:
  rset::get_enum_str() API problem

Status in EPICS Base:
  Triaged

Bug description:
  The recSup.h typed_rset get_enum_str() method has this prototype:

      long (*get_enum_str)(const struct dbAddr *paddr, char *pbuffer);

  The method gets no indication how large pbuffer is, so it's easy for
  it to overflow it, although not by much.

  The bi and bo records both hope it's one byte longer than their
  associated ZNAM/ONAM fields (which are 26 bytes long) because they
  call strncpy(pbuffer,,26) and then write a nil byte to pbuffer[26].

  The mbbi and mbbo records at least don't overflow the buffer they
  assume is 26 bytes long since they don't bother writing the nil byte
  after calling strncpy(pbuffer,,26).

  No other record types in Base define this method, which isn't trivial
  to get called. I think this database should be doing it when lsi gets
  processed, although valgrind doesn't seem to notice the overflow:

  record(bi, bi) {
    field(ZNAM, "26-character-enum-string.")
  }
  record(lsi, "lsi") {
    field(SIZV, 16)  # This is the minimum that lsi actually uses.
    field(INP, "bi")
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1918762/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System