sel record crashes IOC when NVL link read illegal value
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
High
|
Andrew Johnson |
Bug Description
When SELM is "Specified" and NVL points to a record that provides a value which is out of range [0...11], the record support crashes the IOC. The reason is a missing sanity check in fetch_values() before the value is used to increment two pointers.
The bug exists in all versions of base I checked, including 3.13.*
Additional information:
Fix:
-------
Index: selRecord.c
=======
RCS file: /cvs/G/
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 selRecord.c
*** selRecord.c 10 Mar 2006 14:12:49 -0000 1.1.1.1
--- selRecord.c 20 Jul 2007 13:49:19 -0000
***************
*** 416,421 ****
--- 416,422 ----
/* fetch the select index */
if (!RTN_SUCCESS(
+ if (psel->seln >= 12) return -1;
plink += psel->seln;
pvalue += psel->seln;
-------
BTW: I think, SELN should have the PP attribute so that when SELM is "Specified" and NVL is not used/constant, one can caput to SELN.
Original Mantis Bug: mantis-295
http://
I committed this fix to CVS:
Index: selRecord.c ======= ======= ======= ======= ======= ======= ======= ======= ==== epicsmgr/ cvsroot/ epics/base/ src/rec/ selRecord. c,v Specified) : psel,SOFT_ ALARM,MAJOR_ ALARM); psel->seln) ; High_Signal) :
status= dbGetLink( &(psel- >nvl),DBR_ USHORT, &(psel- >seln), 0,0); status) ) return(status);
=======
RCS file: /net/phoebus/
retrieving revision 1.17.2.2
diff -u -b -r1.17.2.2 selRecord.c
--- selRecord.c 29 Aug 2005 19:49:39 -0000 1.17.2.2
+++ selRecord.c 20 Jul 2007 19:15:37 -0000
@@ -346,6 +346,10 @@
pvalue = &psel->a;
switch (psel->selm){
case (selSELM_
+ if (psel->seln >= SEL_MAX) {
+ recGblSetSevr(
+ return(0);
+ }
val = *(pvalue+
break;
case (selSELM_
@@ -417,6 +421,11 @@
if (!RTN_SUCCESS(
+ if (psel->seln >= SEL_MAX) { psel,SOFT_ ALARM,MAJOR_ ALARM);
+ recGblSetSevr(
+ return(-1);
+ }
+
plink += psel->seln;
pvalue += psel->seln;
I am reluctant to set pp for SELN since this could break existing control systems that don't expect it to be pp. I agree that it would make more sense for it to be pp, but making the change could cause some subtle bugs when upgrading an older control system.