netdev - Re: [PATCH] netlink: trim skb to exact size to avoid MSG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Oct 2015 10:56:00 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Ronen Arad <ronen.arad@...el.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] netlink: trim skb to exact size to avoid MSG_TRUNC

On 10/12/15 at 06:15pm, Ronen Arad wrote:
> The available room in the skb allocated in netlink_dump for iproute2
> show requests (e.g. "ip link [show]", "bridge [-c] vlan show") should
> be trimmed to the exact size requested in order to avoid MSG_TRUNC flag
> set in netlink_recvmg.
> This was handled properly for small skb allocated when no interface has
> many VLANs configured. This patch applies the same logic to larger skbs
> which are allocated using the calculated min_dump_alloc size.
> 
> Signed-off-by: Ronen Arad <ronen.arad@...el.com>

Wouldn't this imply a bug in which rtnl_calcit() does not account for
some data that is later dumped? How else could the skb end up being
larger than what alloc_size accounts for at this point unless we end
up stuffing 2x smallish messages into the padded projection of the
calculated maximum message size of that type. Is that what you are
seeing?

Regardless of that, alloc_size is likely larger than nlk->max_recvmsg_len
anyway at this point so unless the reader suddenly provides a different
message size or does peeking it will likely still be truncated.

I'm just trying to understand which exact case you are solving here.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html