Bug 184296 - mailx overflow of short used to hold message length and message block pointers.
mailx overflow of short used to hold message length and message block pointers.
Status: CLOSED DUPLICATE of bug 184139
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mailx (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-07 16:19 EST by Darryl Dixon
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-18 08:24:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 58672 None None None Never

  None (edit)
Description Darryl Dixon 2006-03-07 16:19:31 EST
Description of problem:
as per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58672

Version-Release number of selected component (if applicable):
ALL releases of RHEL to date

How reproducible:
Always.

Steps to Reproduce:
1.Either create a message with more lines than a short, or,
2.Create many messages such that the amount of data is greater than a short
3.etc.
  
Actual results:
Either bad display of messages, or a fseek() panic, etc.

Expected results:
Should display mail correctly

Additional info: Has been fixed in FC for some time, and the bugfix has been in
bugzilla for even longer.  The patch in referenced bugzilla works perfectly.
Comment 1 Radek Vokal 2006-08-04 07:37:24 EDT
According to ug #58672 patch exists - easy fix. This is the only bug for mailx
so far, please feel free to reject it. 
Comment 2 Darryl Dixon 2006-08-04 20:34:36 EDT
Excuse me for my ignorance, but what exactly does 'reject it' mean?  Why is it
considered acceptable to leave a bug in RHEL4 that has been fixed upstream for
years?

This has actually bitten us in production and I suppose we could log the job as
a support call, but really, why bother with Bugzilla at all then?
Comment 3 Matthew Miller 2006-11-16 13:04:06 EST
bug #58672 notes that this was fixed in 2004, and indeed, it does appear fixed
in FC4 and on. This seems like a good candidate for a quarterly update.
Comment 4 Daniel Riek 2006-12-17 00:00:02 EST
The problem is that we have to mediate the amount of change introduced in the
already released versions of RHEL which are used in production environments
Every change bears the risk of regression and side-effects and also our
resources are limited so that we need to prioritize components we change in
order to be able to focus on the right problems. 

The prioritization amongst other factors is based on the severity of the
problem, the broadness of its impact, customer issues reported via our support
organization and the total number of issues against a specific component (e.g.
in this case mailx). 

The comment about "rejecting" has to be seen in this context: we have no other
issues open for mailx in RHEL3, non via support escalation, and we have no other
data justifying a high prioritization. So for a regular update release we would
not prioritize mailx very high and it probably would be deferred to a later
release because components with more critical isues would take priority. In the
later release we would then re-prioritize. Especially if there is a number of
open issues we would address approve updating the component.

Now for the specific case of RHEL3, we are beyond the Full Support and in the
Deployment phase of it's life cycle. U8 already was an extention of that phase
and now RHEL3 is in transition to the Maintenance phase. So at this poing we are
additionally reducing the change to be introduced
(http://www.redhat.com/security/updates/)

Now we indeed ask our customers to report their production issues via our
support organization by phone, email or the support web interface (partly
depending on the SLA level) instead of directly filing in Bugzilla. 

Bugzilla is a development tool, not a support tool. It is correct that Bugzilla
plays an important role in our processes and all bugs go via Bugzilla. Red Hat
actually is working on making more of the bugs we are working on publicly
visible in Bugzilla as they are referenced in the errata. But in order to ensure
the right prioritization, customer issues need to come via the support organization.

I hope that explains a bit what's going on.

I do not see a way we can fix this mailx issue in RHEL 3.9.
Comment 5 Daniel Riek 2006-12-17 00:07:14 EST
One little clarification: we actually ask customers to always report issues via
the support organization. - Not only now.
Comment 6 RHEL Product and Program Management 2006-12-17 00:20:37 EST
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 7 Matthew Miller 2006-12-17 07:43:59 EST
Errr, okay, that long message is nice for RHEL3. However, this issue also exists
in RHEL4, as noted in the comments above. Moving to RHEL4 and reopening.
Comment 8 Ivana Varekova 2006-12-18 08:24:44 EST

*** This bug has been marked as a duplicate of 184139 ***
Comment 9 Darryl Dixon 2007-02-21 16:09:06 EST
I am astounded by this thread. How is anyone helped by us logging a formal
support call for this trivial fix? Will RHEL5 also have this bug when it is
released? Does it not bother anyone that this problem is an overflow?
(hello!!!!???) How does marking this as a duplicate of the CLOSED Red Hat 7.1(!)
bug help to resolve it for RHEL4?

Crazy. I don't understand why *anyone* in the public would bother using Bugzilla
when the response is, basically, "we can't be bothered".

Just astounding.

Anyway, I'm off to log a formal support request for a RHEL4 bug that is
affecting us reading our mail.
Comment 10 Matthew Miller 2007-02-21 16:22:37 EST
Hmmm. There seems to be an advisory which fixes bug #18413

http://rhn.redhat.com/errata/RHBA-2006-0687.html

and this is marked as a duplicate of that.

However, that seems to have been only put out as an update for "Other", not as
an actual RHEL 4 update -- weird.
Comment 11 Darryl Dixon 2007-02-21 17:17:26 EST
Hmm, weird, somehow I ended up at the RedHat 7.1 entry when I clicked the
'duplicate' link instead of the RHEL4 one with the errata referenced. Odd.
Anyhow, nice to see it's been/being fixed - even if it hasn't been released
officially for RHEL4 yet...

Note You need to log in before you can comment on or make changes to this bug.