Menu ▾ ▴

#3406 amf: amfd crashes on delete of non-matching type attribute value (attr-=)

5.27.01
fixed
Nguyen Tran Trung Hau
None
defect
amf
d
major
False
3 days ago
2026-10-09
Nguyen Tran Trung Hau
No

osafamfd NULL-pointer dereference at sg.cc:930 - nonmatching DELETE of saAmfSGType on locked SG crashes the active AMF director and reboots the node.
From sg.cc, ccb_apply_modify_hdlr walks the attrMods list of the CCB modify operation. For each mod it sets up 2 things:

void *value = nullptr;
...
if ((attr_mod->modType == SA_IMM_ATTR_VALUES_DELETE) ||
          (attribute->attrValues == nullptr)) {
        /* Attribute value is deleted, revert to default value */
        value_is_deleted = true; // value stays NULL
 } else {
        /* Attribute value is modified */
        value_is_deleted = false;
        value = attribute->attrValues[0];
 }

For DELETE mods, value is never assigned, every attribute branch checks value_is_deleted and reverts to a default instead of touching value, except the saAmfSGType:

if (!strcmp(attribute->attrName, "saAmfSGType")) {
        SaNameT sg_type_name = *((SaNameT *)value); // NULL deref on DELTE

The execution flow for saAmfSGType:

  1. sg_ccb_completed_modify_hdlr() sees value_is_deleted for saAmfSGType
    and does "continue" (sg.cc:617-618) — DELETE approved unchecked.
  2. sg_ccb_apply_modify_hdlr() leaves value=NULL for the DELETE mod
    (sg.cc:919-927).
  3. The saAmfSGType branch is the only attribute branch that dereferences
    value without checking value_is_deleted (sg.cc:929-930):
    "SaNameT sg_type_name = ((SaNameT )value)" — NULL deref.
  4. amfd dies with SIGSEGV; osafamfnd sees POLLERR on the amfd fifo and
    calls opensaf_reboot() — the node reboots. rc=0 at the client because
    immModel_ccbCommit completes before the apply upcall reaches the OI.

Test scenario:

  1. Cluster running, SC-1 as Active controller.
  2. Create an empty SG under a non-OpenSAF app (SGs under safApp=OpenSAF
    reject admin operations)
  3. Lock the SG (admin state != UNLOCKED selects the vulnerable arm)
  4. Delete a value that is NOT the current value

Expected: CCB rejected with a validation error.
Observed: "The system is going down for reboot NOW!" —
amfd SIGSEGV, nid reboots the node.

Reproduced output:

#1. create an empty SG:
SC-2-1:~ # immcfg -c SaAmfSG \
  -a 'saAmfSGType=safVersion=4.0.0,safSgType=OpenSafSgTypeNoRed' \
  safSg=repro930,safApp=safAmfService
SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
saAmfSGAdminState=1

#2. lock the SG
SC-2-1:~ # immadm -o 2 safSg=repro930,safApp=safAmfService
SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
saAmfSGAdminState=2

#3. delete a value that isn't there (SG is NoRed, delete 2N)
SC-2-1:~ # immcfg -a 'saAmfSGType-=safVersion=4.0.0,safSgType=OpenSafSgType2N' \
>   safSg=repro930,safApp=safAmfService ; echo "rc=$?"
rc=0
The system is going down for reboot NOW!

The same single command also crashes saAmfSUType and saAmfCompType:

  1. su.cc:2055-2066 saAmfSUType — identical continue/deref pattern, but
    NO admin-state gate: crashes in any SU state.
  2. comp.cc:2138 + comptype.cc:49 saAmfCompType — deleted DN resolves to
    no comptype, avd_comptype_add_comp() derefs comp->comp_type=NULL.
  3. csi.cc:655/1010 saAmfCSType — no crash but silent divergence

Related

Tickets: #3406

Discussion

  • Nagendra Kumar

    Nagendra Kumar - 2026-10-09

    Hi Nguyen,
    The ticket is giving very little description. Can you please add reproducable steps? What is the scenario?
    Thanks,
    Nagendra, nagendra@gethighavailability.com
    contact@gethighavailability.com
    High Availability Solutions

     

    • Nguyen Tran Trung Hau

      Nguyen Tran Trung Hau - 2026-10-09

      Hi Nagendra,

      Thanks for the quick review.
      I have pushed the full reproduction case into the description.
      I will update a suggested fix patch later.

      Regards,
      Hau

       

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 2026-10-09

    Reproduced saAmfSUType:

    SC-2-1:~ # immlist safSu=su930,safSg=repro930,safApp=safAmfService
safSu                      SA_STRING_T  safSu=su930
saAmfSUType                SA_NAME_T   safVersion=4.0.0,safSuType=OpenSafSuTypeND
.........
SC-2-1:~ # immcfg -a 'saAmfSUType-=safVersion=4.0.0,safSuType=NONEXISTENT' \
>   safSu=su930,safSg=repro930,safApp=safAmfService ; echo "rc=$?"
rc=0
The system is going down for reboot NOW!

    also lock-in:

    SC-2-1:~ # immadm -o 3 safSg=repro930,safApp=safAmfService
SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
saAmfSGAdminState=3
SC-2-1:~ # immlist -a saAmfSUAdminState safSu=su930,safSg=repro930,safApp=safAmfService
saAmfSUAdminState=3

SC-2-1:~ # immcfg -a 'saAmfSUType-=safVersion=4.0.0,safSuType=NONEXISTENT' \
>   safSu=su930,safSg=repro930,safApp=safAmfService ; echo "rc=$?"
rc=0
The system is going down for reboot NOW!
     

    Last edit: Nguyen Tran Trung Hau 2026-10-09

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 2026-10-09

    Reproduced saAmfCompType — same crash, no admin lock needed:

    SC-2-1:~ # immcfg -c SaAmfCompType \
>   -a saAmfCtCompCategory=8 \
>   -a saAmfCtDefRecoveryOnError=1 \
>   -a saAmfCtDefClcCliTimeout=10000000000 \
>   -a 'saAmfCtRelPathInstantiateCmd=/bin/true' \
>   -a 'saAmfCtRelPathTerminateCmd=/bin/true' \
>   -a 'saAmfCtRelPathCleanupCmd=/bin/true' \
>   safVersion=4.0.0,safCompType=ct930 ; echo "rc=$?"
rc=0

SC-2-1:~ # immcfg -c SaAmfSutCompType \
>   'safMemberCompType=safVersion=4.0.0\,safCompType=ct930,safVersion=4.0.0,safSuType=OpenSafSuTypeND' ; echo "rc=$?"
rc=0

SC-2-1:~ # immcfg -c SaAmfComp \
>   -a 'saAmfCompType=safVersion=4.0.0,safCompType=ct930' \
>   safComp=c930,safSu=su930,safSg=repro930,safApp=safAmfService ; echo "rc=$?"
rc=0

SC-2-1:~ # immcfg -a 'saAmfCompType-=safVersion=4.0.0,safCompType=NONEXISTENT' \
>   safComp=c930,safSu=su930,safSg=repro930,safApp=safAmfService ; echo "rc=$?"
rc=0
The system is going down for reboot NOW!
     

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 2026-10-09

    Reproduced saAmfCSType — same DELETE mishandling, but no crash.
    Instead it silently diverges the amfd-internal model from IMM.

    SC-2-1:~ # immcfg -c SaAmfCSBaseType safCSType=cst930
SC-2-1:~ # immcfg -c SaAmfCSType safVersion=4.0.0,safCSType=cst930
SC-2-1:~ # immcfg -c SaAmfCSBaseType safCSType=cst931
SC-2-1:~ # immcfg -c SaAmfCSType safVersion=4.0.0,safCSType=cst931
SC-2-1:~ # immcfg -c SaAmfCSI \
>   -a 'saAmfCSType=safVersion=4.0.0,safCSType=cst930' \
>   safCsi=csi930,safSi=si930,safApp=safAmfService
SC-2-1:~ # immadm -o 2 safSi=si930,safApp=safAmfService

    Trigger — DELETE

    SC-2-1:~ # immcfg -a 'saAmfCSType-=safVersion=4.0.0,safCSType=cst931' \
>   safCsi=csi930,safSi=si930,safApp=safAmfService ; echo "rc=$?"
rc=0

SC-2-1:~ # immlist -a saAmfCSType safCsi=csi930,safSi=si930,safApp=safAmfService
saAmfCSType=safVersion=4.0.0,safCSType=cst930
     

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 2026-10-09
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -57,6 +57,7 @@
 SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
 saAmfSGAdminState=2

+#3. delete a value that isn't there (SG is NoRed, delete 2N)
 SC-2-1:~ # immcfg -a 'saAmfSGType-=safVersion=4.0.0,safSgType=OpenSafSgType2N' \
 >   safSg=repro930,safApp=safAmfService ; echo "rc=$?"
 rc=0
     

  • Nagendra Kumar

    Nagendra Kumar - 2026-10-09

    Thanks Nguyen, wonderful, good catch!
    Thanks,
    Nagendra, nagendra@gethighavailability.com
    contact@gethighavailability.com
    High Availability Solutions

     

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 3 days ago
    • status: assigned --> review
     

    • Nagendra Kumar

      Nagendra Kumar - 3 days ago

      Hi Nguyen,

      The fix looks good to me, ack.

      Thanks,
      Nagendra, nagendra@gethighavailability.com nagendra@gethighavailability.com
      contact@gethighavailability.com contact@gethighavailability.com
      High Availability Solutions

      From: Nguyen Tran Trung Hau via Opensaf-tickets opensaf-tickets@lists.sourceforge.net
      Sent: 19 October 2026 13:57
      To: opensaf-tickets@lists.sourceforge.net
      Cc: Nguyen Tran Trung Hau trunghau963@users.sourceforge.net
      Subject: [tickets] [opensaf:tickets] #3406 amf: amfd crashes on delete of non-matching type attribute value (attr-=)

      • status: assigned --> review

      [tickets:#3406] https://sourceforge.net/p/opensaf/tickets/3406/ amf: amfd crashes on delete of non-matching type attribute value (attr-=)

      Status: review
      Milestone: 5.27.01
      Created: Fri Oct 09, 2026 07:27 AM UTC by Nguyen Tran Trung Hau
      Last Updated: Fri Oct 09, 2026 10:23 AM UTC
      Owner: Nguyen Tran Trung Hau

      osafamfd NULL-pointer dereference at sg.cc:930 - nonmatching DELETE of saAmfSGType on locked SG crashes the active AMF director and reboots the node.
      From sg.cc, ccb_apply_modify_hdlr walks the attrMods list of the CCB modify operation. For each mod it sets up 2 things:

      void value = nullptr;
      ...
      if ((attr_mod->modType == SA_IMM_ATTR_VALUES_DELETE) ||
      (attribute->attrValues == nullptr)) {
      /       Attribute value is deleted, revert to default value /
      value_is_deleted = true; // value stays NULL
      } else {
      /       Attribute value is modified */
      value_is_deleted = false;
      value = attribute->attrValues[0];
      }

      For DELETE mods, value is never assigned, every attribute branch checks value_is_deleted and reverts to a default instead of touching value, except the saAmfSGType:

      if (!strcmp(attribute->attrName, "saAmfSGType")) {
      SaNameT sg_type_name = ((SaNameT )value); // NULL deref on DELTE

      The execution flow for saAmfSGType:

      1. sg_ccb_completed_modify_hdlr() sees value_is_deleted for saAmfSGType
        and does "continue" (sg.cc:617-618) — DELETE approved unchecked.
      2. sg_ccb_apply_modify_hdlr() leaves value=NULL for the DELETE mod
        (sg.cc:919-927).
      3. The saAmfSGType branch is the only attribute branch that dereferences
        value without checking value_is_deleted (sg.cc:929-930):
        "SaNameT sg_type_name = ((SaNameT )value)" — NULL deref.
      4. amfd dies with SIGSEGV; osafamfnd sees POLLERR on the amfd fifo and
        calls opensaf_reboot() — the node reboots. rc=0 at the client because
        immModel_ccbCommit completes before the apply upcall reaches the OI.

      Test scenario:

      1. Cluster running, SC-1 as Active controller.
      2. Create an empty SG under a non-OpenSAF app (SGs under safApp=OpenSAF
        reject admin operations)
      3. Lock the SG (admin state != UNLOCKED selects the vulnerable arm)
      4. Delete a value that is NOT the current value

      Expected: CCB rejected with a validation error.
      Observed: "The system is going down for reboot NOW!" —
      amfd SIGSEGV, nid reboots the node.

      Reproduced output:

      1. create an empty SG:

      SC-2-1:~ # immcfg -c SaAmfSG \
      -a 'saAmfSGType=safVersion=4.0.0,safSgType=OpenSafSgTypeNoRed' \
      safSg=repro930,safApp=safAmfService
      SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
      saAmfSGAdminState=1

      2. lock the SG

      SC-2-1:~ # immadm -o 2 safSg=repro930,safApp=safAmfService
      SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
      saAmfSGAdminState=2

      3. delete a value that isn't there (SG is NoRed, delete 2N)

      SC-2-1:~ # immcfg -a 'saAmfSGType-=safVersion=4.0.0,safSgType=OpenSafSgType2N' \

      safSg=repro930,safApp=safAmfService ; echo "rc=$?"
      rc=0
      The system is going down for reboot NOW!

      The same single command also crashes saAmfSUType and saAmfCompType:

      1. su.cc:2055-2066 saAmfSUType — identical continue/deref pattern, but
        NO admin-state gate: crashes in any SU state.
      2. comp.cc:2138 + comptype.cc:49 saAmfCompType — deleted DN resolves to
        no comptype, avd_comptype_add_comp() derefs comp->comp_type=NULL.
      3. csi.cc:655/1010 saAmfCSType — no crash but silent divergence

      Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/

      To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

       

      Related

      Tickets: #3406
      Tickets: tickets

      alternate

      • Kanakam Mohan Krishna

        Kanakam Mohan Krishna - 3 days ago

        Hi Nguyen,

        Do you see the similar issues in other objects like SU, SI, etc.?

        Thanks,

        Mohan, contact@gethighavailability.com

        High Availability Solutions

        From: Nagendra Kumar via Opensaf-tickets [mailto:opensaf-tickets@lists.sourceforge.net]
        Sent: 19 October 2026 17:26
        To: opensaf-tickets@lists.sourceforge.net
        Cc: Nagendra Kumar
        Subject: [tickets] [opensaf:tickets] Re: #3406 amf: amfd crashes on delete of non-matching type attribute value (attr-=)

        Hi Nguyen,

        The fix looks good to me, ack.

        Thanks,
        Nagendra, nagendra@gethighavailability.com nagendra@gethighavailability.com
        contact@gethighavailability.com contact@gethighavailability.com
        High Availability Solutions

        From: Nguyen Tran Trung Hau via Opensaf-tickets opensaf-tickets@lists.sourceforge.net
        Sent: 19 October 2026 13:57
        To: opensaf-tickets@lists.sourceforge.net
        Cc: Nguyen Tran Trung Hau trunghau963@users.sourceforge.net
        Subject: [tickets] https://sourceforge.net/p/opensaf/tickets/_discuss/ [opensaf:tickets] #3406 amf: amfd crashes on delete of non-matching type attribute value (attr-=)

        • status: assigned --> review

        [tickets:#3406] https://sourceforge.net/p/opensaf/tickets/3406/ https://sourceforge.net/p/opensaf/tickets/3406/ amf: amfd crashes on delete of non-matching type attribute value (attr-=)

        Status: review
        Milestone: 5.27.01
        Created: Fri Oct 09, 2026 07:27 AM UTC by Nguyen Tran Trung Hau
        Last Updated: Fri Oct 09, 2026 10:23 AM UTC
        Owner: Nguyen Tran Trung Hau

        osafamfd NULL-pointer dereference at sg.cc:930 - nonmatching DELETE of saAmfSGType on locked SG crashes the active AMF director and reboots the node.
        From sg.cc, ccb_apply_modify_hdlr walks the attrMods list of the CCB modify operation. For each mod it sets up 2 things:

        void value = nullptr;
        ...
        if ((attr_mod->modType == SA_IMM_ATTR_VALUES_DELETE) ||
        (attribute->attrValues == nullptr)) {
        / Attribute value is deleted, revert to default value /
        value_is_deleted = true; // value stays NULL
        } else {
        / Attribute value is modified */
        value_is_deleted = false;
        value = attribute->attrValues[0];
        }

        For DELETE mods, value is never assigned, every attribute branch checks value_is_deleted and reverts to a default instead of touching value, except the saAmfSGType:

        if (!strcmp(attribute->attrName, "saAmfSGType")) {
        SaNameT sg_type_name = ((SaNameT )value); // NULL deref on DELTE

        The execution flow for saAmfSGType:

        1. sg_ccb_completed_modify_hdlr() sees value_is_deleted for saAmfSGType
          and does "continue" (sg.cc:617-618) — DELETE approved unchecked.
        2. sg_ccb_apply_modify_hdlr() leaves value=NULL for the DELETE mod
          (sg.cc:919-927).
        3. The saAmfSGType branch is the only attribute branch that dereferences
          value without checking value_is_deleted (sg.cc:929-930):
          "SaNameT sg_type_name = ((SaNameT )value)" — NULL deref.
        4. amfd dies with SIGSEGV; osafamfnd sees POLLERR on the amfd fifo and
          calls opensaf_reboot() — the node reboots. rc=0 at the client because
          immModel_ccbCommit completes before the apply upcall reaches the OI.

        Test scenario:

        1. Cluster running, SC-1 as Active controller.
        2. Create an empty SG under a non-OpenSAF app (SGs under safApp=OpenSAF
          reject admin operations)
        3. Lock the SG (admin state != UNLOCKED selects the vulnerable arm)
        4. Delete a value that is NOT the current value

        Expected: CCB rejected with a validation error.
        Observed: "The system is going down for reboot NOW!" —
        amfd SIGSEGV, nid reboots the node.

        Reproduced output:

        1. create an empty SG:

        SC-2-1:~ # immcfg -c SaAmfSG \
        -a 'saAmfSGType=safVersion=4.0.0,safSgType=OpenSafSgTypeNoRed' \
        safSg=repro930,safApp=safAmfService
        SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
        saAmfSGAdminState=1

        1. lock the SG

        SC-2-1:~ # immadm -o 2 safSg=repro930,safApp=safAmfService
        SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
        saAmfSGAdminState=2

        1. delete a value that isn't there (SG is NoRed, delete 2N)

        SC-2-1:~ # immcfg -a 'saAmfSGType-=safVersion=4.0.0,safSgType=OpenSafSgType2N' \

        safSg=repro930,safApp=safAmfService ; echo "rc=$?"
        rc=0
        The system is going down for reboot NOW!

        The same single command also crashes saAmfSUType and saAmfCompType:

        1. su.cc:2055-2066 saAmfSUType — identical continue/deref pattern, but
          NO admin-state gate: crashes in any SU state.
        2. comp.cc:2138 + comptype.cc:49 saAmfCompType — deleted DN resolves to
          no comptype, avd_comptype_add_comp() derefs comp->comp_type=NULL.
        3. csi.cc:655/1010 saAmfCSType — no crash but silent divergence

        Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/

        To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

        [tickets:#3406] https://sourceforge.net/p/opensaf/tickets/3406/ amf: amfd crashes on delete of non-matching type attribute value (attr-=)

        Status: review
        Milestone: 5.27.01
        Created: Fri Oct 09, 2026 07:27 AM UTC by Nguyen Tran Trung Hau
        Last Updated: Mon Oct 19, 2026 08:27 AM UTC
        Owner: Nguyen Tran Trung Hau

        osafamfd NULL-pointer dereference at sg.cc:930 - nonmatching DELETE of saAmfSGType on locked SG crashes the active AMF director and reboots the node.
        From sg.cc, ccb_apply_modify_hdlr walks the attrMods list of the CCB modify operation. For each mod it sets up 2 things:

        void value = nullptr;
        ...
        if ((attr_mod->modType == SA_IMM_ATTR_VALUES_DELETE) ||
        (attribute->attrValues == nullptr)) {
        /         Attribute value is deleted, revert to default value /
        value_is_deleted = true; // value stays NULL
        } else {
        /         Attribute value is modified */
        value_is_deleted = false;
        value = attribute->attrValues[0];
        }

        For DELETE mods, value is never assigned, every attribute branch checks value_is_deleted and reverts to a default instead of touching value, except the saAmfSGType:

        if (!strcmp(attribute->attrName, "saAmfSGType")) {
        SaNameT sg_type_name = ((SaNameT )value); // NULL deref on DELTE

        The execution flow for saAmfSGType:

        1. sg_ccb_completed_modify_hdlr() sees value_is_deleted for saAmfSGType
          and does "continue" (sg.cc:617-618) — DELETE approved unchecked.
        2. sg_ccb_apply_modify_hdlr() leaves value=NULL for the DELETE mod
          (sg.cc:919-927).
        3. The saAmfSGType branch is the only attribute branch that dereferences
          value without checking value_is_deleted (sg.cc:929-930):
          "SaNameT sg_type_name = ((SaNameT )value)" — NULL deref.
        4. amfd dies with SIGSEGV; osafamfnd sees POLLERR on the amfd fifo and
          calls opensaf_reboot() — the node reboots. rc=0 at the client because
          immModel_ccbCommit completes before the apply upcall reaches the OI.

        Test scenario:

        1. Cluster running, SC-1 as Active controller.
        2. Create an empty SG under a non-OpenSAF app (SGs under safApp=OpenSAF
          reject admin operations)
        3. Lock the SG (admin state != UNLOCKED selects the vulnerable arm)
        4. Delete a value that is NOT the current value

        Expected: CCB rejected with a validation error.
        Observed: "The system is going down for reboot NOW!" —
        amfd SIGSEGV, nid reboots the node.

        Reproduced output:

        1. create an empty SG:

        SC-2-1:~ # immcfg -c SaAmfSG \
        -a 'saAmfSGType=safVersion=4.0.0,safSgType=OpenSafSgTypeNoRed' \
        safSg=repro930,safApp=safAmfService
        SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
        saAmfSGAdminState=1

        2. lock the SG

        SC-2-1:~ # immadm -o 2 safSg=repro930,safApp=safAmfService
        SC-2-1:~ # immlist -a saAmfSGAdminState safSg=repro930,safApp=safAmfService
        saAmfSGAdminState=2

        3. delete a value that isn't there (SG is NoRed, delete 2N)

        SC-2-1:~ # immcfg -a 'saAmfSGType-=safVersion=4.0.0,safSgType=OpenSafSgType2N' \

        safSg=repro930,safApp=safAmfService ; echo "rc=$?"
        rc=0
        The system is going down for reboot NOW!

        The same single command also crashes saAmfSUType and saAmfCompType:

        1. su.cc:2055-2066 saAmfSUType — identical continue/deref pattern, but
          NO admin-state gate: crashes in any SU state.
        2. comp.cc:2138 + comptype.cc:49 saAmfCompType — deleted DN resolves to
          no comptype, avd_comptype_add_comp() derefs comp->comp_type=NULL.
        3. csi.cc:655/1010 saAmfCSType — no crash but silent divergence

        Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/

        To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

         

        Related

        Tickets: #3406
        Tickets: tickets

        alternate

  • Thang Duc Nguyen

    Thang Duc Nguyen - 3 days ago
    • status: review --> fixed
     

  • Thang Duc Nguyen

    Thang Duc Nguyen - 3 days ago

    commit 5ef0f4083826c52de2488fd5a704f12d3ca6051b (HEAD -> develop, origin/develop, ticket-3406)
    Author: Hau Tran Trung Nguyen Hau.Nguyen@endava.com
    Date: Fri Oct 16 03:58:49 2026 +0000

    amf: amfd crashes on delete of non-matching type attr value [#3406]

A non-matching delete on saAmfSGType, saAmfSUType, saAmfCompType or
saAmfCSType passes completed validation unchecked and crashes amfd
in apply.

Reject DELETE on these attributes in the completed handler.
     

  • Nguyen Tran Trung Hau

    Nguyen Tran Trung Hau - 3 days ago

    Hi Mohan,

    Yes, it's not just sg.cc. The same pattern crashes saAmfSUType and saAmfCompType too (NULL deref at su.cc:2064, osafassert at comp.cc), and saAmfCSType doesn't crash but quietly retypes the CSI to the DN being deleted.
    All of those are covered by the new patch already.

    Regards,
    Hau

     

Log in to post a comment.

veeam logo