[Bug 1256] ftpd can generate a misaligned access
Ralf Corsepius
ralf.corsepius at rtems.org
Tue Aug 28 15:07:02 UTC 2007
On Tue, 2007-08-28 at 10:01 -0500, Joel Sherrill wrote:
> Ralf Corsepius wrote:
> > On Tue, 2007-08-28 at 09:06 -0500, rtems-bugs at rtems.org wrote:
> >
> >> http://www.rtems.org/bugzilla/show_bug.cgi?id=1256
> >>
> >>
> >> joel.sherrill at oarcorp.com changed:
> >>
> >> What |Removed |Added
> >> ----------------------------------------------------------------------------
> >> Status|NEW |RESOLVED
> >> Resolution| |FIXED
> >>
> >>
> >>
> >>
> >> ------- Comment #2 from joel.sherrill at oarcorp.com 2007-08-28 09:06 -------
> >> Patch committed to 4.7 and CVS head.
> >>
> > I am having strong doubts this patch to fix anything.
> >
> > Joel, can you prove your claim?
> >
> The original report email I received was this:
>
> ============================
> I found a bug in RTEMS 4.7.99.2 FTPD, where an unaligned access may
> occur if the char array 'b' in the function command_port is not aligned
> to a 4 byte boundary. The submitted patch has been tested successfully
> on the LEON3 BSP.
>
> ARCH: SPARC and other architectures not supporting unaligned accesses
> Function: command_port
> bug occurs at row 1456 and 1457 in ftpd.c
>
> CVS diff:
>
> RCS file: /usr1/CVS/rtems/cpukit/ftpd/ftpd.c,v
> retrieving revision 1.13
> diff -r1.13 ftpd.c
> 1439c1439
> < uint8_t b[NUM_FIELDS];
> ---
> > uint8_t b[NUM_FIELDS] __attribute__ ((aligned (4)));
>
> ============================
>
> When I looked at the code, I didn't particularly like adding
> an aligned directive and it appeared to be abusing the bytes.
> I converted the code to use the union. The union should
> be aligned based upon the needs of the strictest member.
>
> The user has confirmed that the union fixes the problem
> on their targets (LEON2/LEON3).
>
> That's all I have. Whether or not it is proof is up for
> debate. :)
Well, that's hardly a proof. I've seen so many urban legends about
alignment to spend much belief in any such hacks any. So far in almost
all cases such hacks in the end have shown to be side-effects of other
bugs (e.g. mis-matches between assumptions on alignment in binutils, GCC
and/BSP).
Ralf
More information about the bugs
mailing list