[LU-6878] Potential NULL pointer dereference in top_trans_stop Created: 19/Jul/15  Updated: 01/Aug/15  Resolved: 01/Aug/15

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Oleg Drokin Assignee: Di Wang
Resolution: Not a Bug Votes: 0
Labels: None

Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

top_trans_stop has this code:

                rc = dt_trans_stop(env, master_st->st_dt, master_st->st_sub_th);
                if (rc < 0) {
                        th->th_result = rc;
                        GOTO(stop_other_trans, rc);
                } else if (tur != NULL && tur->tur_update_records != NULL) {
                        struct llog_update_record *lur;

                        lur = tur->tur_update_records;
....
        if (write_updates) {
                struct llog_update_record *lur;

                /* Stop callback of master will add more updates and also update
                 * master transno, so merge the parameters and updates into one
                 * buffer again */
                rc = prepare_writing_updates(env, tmt);
                if (rc < 0) {
                        CERROR("%s: prepare updates failed: rc = %d\n",
                               master_dev->dd_lu_dev.ld_obd->obd_name, rc);
                        th->th_result = rc;
                        GOTO(stop_other_trans, rc);
                }
                lur = tur->tur_update_records;

So in a very similar bits one makes sure tur is not NULL and the other takes it for granted which is a bit strange and probably hides a bug.



 Comments   
Comment by Di Wang [ 20/Jul/15 ]

You mean tur might be NULL, but if tur is NULL, then write_updates will be false. Do I miss sth here?

Comment by Joseph Gmitter (Inactive) [ 20/Jul/15 ]

Assigning to Di while Oleg investigates the last comment for further guidance.

Comment by Oleg Drokin [ 01/Aug/15 ]

I guess this is indeed a false positive, so resolving.

Generated at Sat Feb 10 02:04:03 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.