From: Shaobo <shaobo@cs.utah.edu>
To: linux-media@vger.kernel.org
Subject: Dead code in v4l2-mem2mem.c?
Date: Thu, 16 Feb 2017 20:47:05 -0700 [thread overview]
Message-ID: <6da009217bbd2e6137ba764ac5c640bf@cs.utah.edu> (raw)
Hi there,
My name is Shaobo He and I am a graduate student at University of Utah.
I am applying a static analysis tool to the Linux device drivers,
looking for NULL pointer dereference and accidentally found a plausible
dead code location in v4l2-mem2mem.c due to undefined behavior.
The following is the problematic code segment
(drivers/media/v4l2-core/v4l2-mem2mem.c),
> 70 static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx
> *m2m_ctx,
> 71 enum v4l2_buf_type
> type)
> 72 {
> 73 if (V4L2_TYPE_IS_OUTPUT(type))
> 74 return &m2m_ctx->out_q_ctx;
> 75 else
> 76 return &m2m_ctx->cap_q_ctx;
> 77 }
> 78
> 79 struct vb2_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx,
> 80 enum v4l2_buf_type type)
> 81 {
> 82 struct v4l2_m2m_queue_ctx *q_ctx;
> 83
> 84 q_ctx = get_queue_ctx(m2m_ctx, type);
> 85 if (!q_ctx)
> 86 return NULL;
> 87
> 88 return &q_ctx->q;
> 89 }
`get_queue_ctx` returns a pointer value that is an addition of the base
pointer address (`m2m_ctx`) to a non-zero offset. The following is the
definition of struct v4l2_m2m_ctx (include/media/v4l2-mem2mem.h),
> 94 struct v4l2_m2m_ctx {
> 95 /* optional cap/out vb2 queues lock */
> 96 struct mutex *q_lock;
> 97
> 98 /* internal use only */
> 99 struct v4l2_m2m_dev *m2m_dev;
> 100
> 101 struct v4l2_m2m_queue_ctx cap_q_ctx;
> 102
> 103 struct v4l2_m2m_queue_ctx out_q_ctx;
> 104
> 105 /* For device job queue */
> 106 struct list_head queue;
> 107 unsigned long job_flags;
> 108 wait_queue_head_t finished;
> 109
> 110 void *priv;
> 111 };
There is a NULL test in a caller of `get_queue_ctx` (line 85), which
appears problematic to me. I’m not sure if it is defined or feasible
under the context of Linux kernel. This blog
(https://wdtz.org/undefined-behavior-in-binutils-causes-segfault.html)
suggests that the NULL check can be optimized away because the only case
that the return value can be NULL triggers pointer overflow, which is
undefined.
Please let me know if it makes sense or not. Thanks for your time and I
am looking forward to your reply.
Best,
Shaobo
next reply other threads:[~2017-02-17 3:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 3:47 Shaobo [this message]
[not found] <002201d288a9$93dd7360$bb985a20$@cs.utah.edu>
2017-02-17 10:26 ` Dead code in v4l2-mem2mem.c? Laurent Pinchart
2017-02-17 18:42 ` Shaobo
2017-02-18 10:53 ` Laurent Pinchart
2017-02-20 19:49 ` Shaobo
2017-02-22 19:54 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6da009217bbd2e6137ba764ac5c640bf@cs.utah.edu \
--to=shaobo@cs.utah.edu \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox