[PATCH 1/6] msgb: Add msgb_resize_area and msgb_copy

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Thu Nov 19 14:34:31 UTC 2015


+/*! \brief Copy an msgb.

I'd write just "a" here, not "an". I seem to be the English nitpicker
among us ;)

+ *
+ *  This function allocates a new msgb, copies the data buffer of msg,
+ *  and adjusts the pointers (incl l1h-l4h) accordingly. The cb part
+ *  is not copied.
+ *  \param[in] msg  The old msgb object
+ *  \param[in] name Human-readable name to be associated with msgb
+ */
+struct msgb *msgb_copy(const struct msgb *msg, const char *name)
+{
[...]
+}
+
+/*! \brief Resize an area within an msgb
+ *
+ *  This resizes a sub area of the msgb data and adjusts the pointers (incl
+ *  l1h-l4h) accordingly. The cb part is not updated. If the area is extended,
+ *  the contents of the extension is undefined. The complete sub area must be a
+ *  part of [data,tail].
+ *
+ *  \param[inout] msg       The msgb object
+ *  \param[in]    area      A pointer to the sub-area
+ *  \param[in]    old_size  The old size of the sub-area
+ *  \param[in]    new_size  The new size of the sub-area
+ *  \returns 0 on success, -1 if there is not enough space to extend the area
+ */
+int msgb_resize_area(struct msgb *msg, uint8_t *area,
+			    size_t old_size, size_t new_size)
+{
+	int rc;
+	uint8_t *rest = area + old_size;
+	int rest_len = msg->len - old_size - (area - msg->data);
+	int delta_size = (int)new_size - (int)old_size;
+
+	if (area < msg->data || rest > msg->tail)
+		MSGB_ABORT(msg, "Sub area is not fully contained in the msg data\n");

Just to be super paranoid: old_size is unsigned, sure, but uint8_t *rest
could wrap when old_size is (accidentally/crafted) passed as very very
large. I could pass area > msg->tail with rest < msg->tail.

Also, if new_size were past INT_MAX, (int)new_size would end up negative.
Same for old_size. My head is spinning a bit from trying to figure out the
result of the subtraction in those cases... ;)

What do you think? Not relevant for any normal use, sure, but should we
rule out those cases entirely?

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151119/57e67d6b/attachment.bin>


More information about the OpenBSC mailing list