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]
Message-ID: <4A812354.8090704@volkswagen.de>
Date:	Tue, 11 Aug 2009 09:52:52 +0200
From:	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>
To:	Andrew Morton <akpm@...ux-foundation.org>, kaber@...sh.net,
	Wolfgang Grandegger <wg@...ndegger.com>
CC:	dbaryshkov@...il.com, bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	"Thuermann, Urs, Dr. (K-EFFI/I)" <urs.thuermann@...kswagen.de>,
	Lothar Wassmann <LW@...O-electronics.de>,
	netdev@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating
 can device

Andrew Morton wrote:
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@...zilla.kernel.org wrote:
>
>   
>> http://bugzilla.kernel.org/show_bug.cgi?id=13954
>>     
>
> Thanks.
>
>   
>>            Summary: Oops in rtnetlink code when creating can device
>>            Product: Networking
>>            Version: 2.5
>>     Kernel Version: 2.6.30-rc5
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: Other
>>         AssignedTo: acme@...stprotocols.net
>>         ReportedBy: dbaryshkov@...il.com
>>         Regression: No
>>
>>
>> I've got a nice oops when looking around new CAN code in kernel.
>>
>> root@...ux86:~# ip link add type can
>> [  713.113325] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [  713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>> [  713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000 
>> [  713.115627] Oops: 0000 [#1] SMP 
>> [  713.115972] last sysfs file:
>> /sys/devices/virtual/backlight/fujitsu-laptop/brightness
>> [  713.116137] Modules linked in:
>> [  713.116137] 
>> [  713.116137] Pid: 1803, comm: ip Not tainted (2.6.31-rc5 #68) 
>> [  713.116137] EIP: 0060:[<c13eecab>] EFLAGS: 00000246 CPU: 0
>> [  713.116137] EIP is at register_netdevice+0xab/0x420
>> [  713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001
>> [  713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34
>> [  713.116137]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> [  713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0
>> task.ti=c61aa000)
>> [  713.116137] Stack:
>> [  713.116137]  c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 c72c6000
>> 00000000
>> [  713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090
>> c61abc18 c6f3d028
>> [  713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46
>> 00000008 c1546f80
>> [  713.116137] Call Trace:
>> [  713.116137]  [<c13f732f>] ? rtnl_create_link+0x4f/0x130
>> [  713.116137]  [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0
>> [  713.116137]  [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>> [  713.116137]  [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0
>> [  713.116137]  [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>> [  713.116137]  [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220
>> [  713.116137]  [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220
>> [  713.116137]  [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0
>> [  713.116137]  [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50
>>     

The problem is, that

ip link add type can

is not possible as you can not create 'real' CAN devices like can0, 
can1, ...

To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use

ip link add type vcan

see drivers/net/can/vcan.c

---

For real hardware CAN devices the netlink interface is only used for the 
configuration of already existing interfaces.
 From a quick view on the rtnl_newlink() function in 
net/core/rtnetlink.c i was not able to find any method to disallow the 
creation of  interfaces, will say: How can a netlink user provide the 
information, that he's not able to create new devices via netlink???

@Patrick: Do you have an idea for this? Is it a new use-case for netlink 
that needs to be implemented?

Regards,
Oliver

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ