linux-kernel - Re: [PATCH v1 2/5] connector/cn_proc: Add filtering to fix some bugs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <D1BAB522-682D-436D-B542-C4444918189F@oracle.com>
Date:   Wed, 15 Mar 2023 20:12:01 +0000
From:   Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "zbr@...emap.net" <zbr@...emap.net>,
        "brauner@...nel.org" <brauner@...nel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "ecree.xilinx@...il.com" <ecree.xilinx@...il.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "socketcan@...tkopp.net" <socketcan@...tkopp.net>,
        "petrm@...dia.com" <petrm@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v1 2/5] connector/cn_proc: Add filtering to fix some bugs


>> 
>> The unbind call will not work because it is for the case of adding and deleting group memberships and hence called from netlink_setsockopt() when  NETLINK_DROP_MEMBERSHIP option is given. We would not be able to distinguish between the drop membership & release cases.
>> The notifier call seems to be for blocked clients? Am not sure if the we need to block/wait on this call to be notified to free/release. Also, the API does not pass in struct sock to free what we want, so we will need to change that everywhere it is currently used.
> 
> I think that adding the new release callback is acceptable.
> I haven't seen your v2 before replying.

Thanks, so I will wait for your comments on v2 before sending updated patch.

> 
>> As for using sk_user_data - this field seems to be used by different applications in different ways depending on how they need to use data. If we use a new field in netlink_sock, we would need to add a new API function to allocate this member, similar to release, because it seems you cannot access netlink_sock outside of af_netlink, or at least I do not see any current access to it, and functions like nlk_sk are static. Also, if we add an allocation function, we won’t know the first time the client sends it’s data (we need to know “initial” in the patches), so we will need to add a new field in the socket to indicate first access or add a lot more infrastructure in cn_proc to store each client’s information.
> 
> Alright, I guess we can risk the sk_user_data, and see if anything
> explodes. Normally higher protocol wraps the socket structure in its
> own structure and the sk_user_data pointer is for an in-kernel user
> of the socket (i.e. in kernel client). But "classic netlink" is all
> legacy code (new subsystem use the generic netlink overlay) so trying
> to decode now why things are the way they are and fixing the structure
> would be a major effort :(

Ok, thanks!