Description of problem: In bcm_connect() (in net/can/bcm.c), there is the following code: sprintf(bo->procname, "%p", sock); "procname" is a 9-byte char array. On 64-bit platforms, up to 17 bytes may be copied into the buffer. Fortunately, structure padding will most likely prevent this from being a problem, except for the trailing NULL byte, which may overwrite the first byte of the next heap object. Reference: http://www.spinics.net/lists/netdev/msg145791.html Acknowledgements: Red Hat would like to thank Dan Rosenberg for reporting this issue.
Statement: The Linux kernel as shipped with Red Hat Enterprise Linux 3, 4 and 5 did not include CAN bus subsystem support, and therefore are not affected by this issue. Future kernel updates in Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG may address this flaw.
Proposed patch: http://www.spinics.net/lists/netdev/msg146469.html http://www.spinics.net/lists/netdev/msg146270.html
Upstream commit: http://git.kernel.org/linus/0597d1b99fcfc2c0eada09a698f85ed413d4ba84
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2010:0958 https://rhn.redhat.com/errata/RHSA-2010-0958.html
CAN BCM calls can_proto_register() that calls proto_register(cp->prot, 0) ie. it does not request to create per protocol slab cache with protocol defined object size. Because the sizeof(bcm_sock) is ~0x2d0 on x86_64 it falls into the kmalloc-1024 bucket leaving ~300 bytes as padding. Here off-by-one won't help much.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0007 https://rhn.redhat.com/errata/RHSA-2011-0007.html