netdev - Re: [PATCH net-next 10/18] ionic: Add management of rx filters

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, 25 Jun 2019 16:37:29 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 10/18] ionic: Add management of rx filters

On Thu, 20 Jun 2019 13:24:16 -0700, Shannon Nelson wrote:
> +int ionic_rx_filter_save(struct lif *lif, u32 flow_id, u16 rxq_index,
> +			 u32 hash, struct ionic_admin_ctx *ctx)
> +{
> +	struct device *dev = lif->ionic->dev;
> +	struct hlist_head *head;
> +	struct rx_filter *f;
> +	unsigned int key;
> +
> +	f = devm_kzalloc(dev, sizeof(*f), GFP_KERNEL);
> +	if (!f)
> +		return -ENOMEM;
> +
> +	f->flow_id = flow_id;
> +	f->filter_id = le32_to_cpu(ctx->comp.rx_filter_add.filter_id);
> +	f->rxq_index = rxq_index;
> +	memcpy(&f->cmd, &ctx->cmd, sizeof(f->cmd));
> +
> +	INIT_HLIST_NODE(&f->by_hash);
> +	INIT_HLIST_NODE(&f->by_id);
> +
> +	switch (le16_to_cpu(f->cmd.match)) {
> +	case RX_FILTER_MATCH_VLAN:
> +		key = le16_to_cpu(f->cmd.vlan.vlan) & RX_FILTER_HLISTS_MASK;
> +		break;
> +	case RX_FILTER_MATCH_MAC:
> +		key = *(u32 *)f->cmd.mac.addr & RX_FILTER_HLISTS_MASK;
> +		break;
> +	case RX_FILTER_MATCH_MAC_VLAN:
> +		key = le16_to_cpu(f->cmd.mac_vlan.vlan) & RX_FILTER_HLISTS_MASK;
> +		break;
> +	default:

I know you use devm_kzalloc() but can't this potentially keep arbitrary
amounts of memory held until the device is removed (and it's the entire
device not just a LIF)?

> +		return -ENOTSUPP;

EOPNOTSUPP, please do not use ENOTSUPP in the drivers.  It's a high
error code, unknown to libc.  We should use EOPNOTSUPP or EINVAL.

> +	}