Bug 1091547 - [GSS] (6.2.x) DataSourceProvider uses an insecure method to read the input stream
Summary: [GSS] (6.2.x) DataSourceProvider uses an insecure method to read the input st...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: RESTEasy
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: CR1
: EAP 6.2.4
Assignee: Dominik Pospisil
QA Contact: Katerina Odabasi
Russell Dickenson
Depends On: 1080420 1103110 1118893
Blocks: eap62-cp04-blockers 1091552 1105696
TreeView+ depends on / blocked
Reported: 2014-04-25 20:20 UTC by Kyle Lape
Modified: 2018-12-05 18:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The datasource provider that ships with RESTeasy uses the `InputStream::available` method, which, as stated in the Javadoc, is inappropriate: 'Note that while some implementations of InputStream will return the total number of bytes in the stream, many will not. It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.' This release of JBoss EAP 6 avoids using this method.
Clone Of: 1080420
: 1091552 (view as bug list)
Last Closed: 2014-08-07 12:12:20 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RESTEASY-779 0 Major Closed DataSourceProvider does not properly read InputStream 2016-08-02 16:15:27 UTC

Description Kyle Lape 2014-04-25 20:20:50 UTC
Description of problem:

DataSourceProvider that comes with RESTeasy is using the method InputStream::available method, which shouldn't be used as it is mention on InputStream's Javadoc[1]:

" Note that while some implementations of InputStream will return the total number of bytes in the stream, many will not. It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream."

Customers have mention that they are experiencing issues when using this provider

[1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#available%28%29

The solution would be avoid the usage of InputStream::available method.

Comment 2 JBoss JIRA Server 2014-05-06 01:04:41 UTC
Kyle Lape <kyle.lape> updated the status of jira RESTEASY-779 to Resolved

Comment 3 Weinan Li 2014-06-02 17:18:36 UTC
I've checked the branch created by Petr:

commit 8e0586bd317bedddaf14c95ab1c68231cabe2f00
Author: Petr Sakař <psakar>
Date:   Wed Mar 26 16:30:40 2014 +0100

    [RESTEASY-779] DataSourceProvider does not properly read InputStream

commit e2d7ffba9a2d32a6dd6f96b5dda7f8e54a2fec9c
Author: Weinan Li <weli>
Date:   Fri Sep 27 23:49:14 2013 +0800

    add necessary spring deps

Which is based on branch 'remotes/origin/2.3.7.Final-redhat'. This is not the correct branch to use for patching 2.3.7. Because we currently have


commit 89a702e00be8bef1d497e0d5a79107e836f6ad7b
Author: Weinan Li <weli>
Date:   Thu Apr 24 20:48:31 2014 +0800

    initial import of

If we want to patch RESTEasy for EAP 6.2.0, we need to go through the one-off patch process.

Comment 4 Weinan Li 2014-06-02 17:30:30 UTC
Upstream Branch_2_3:

commit 6e9f8182311c8206686e08f20694f76b88a95d6a
Merge: e61ea79 deae5bf
Author: Bill Burke <bburke>
Date:   Wed Mar 26 18:11:12 2014 -0400

    Merge pull request #478 from psakar/Branch_2_3

    [RESTEASY-779] DataSourceProvider does not properly read InputStream

Upstream Branch_2_3_7: Patch not found. Lastest PR is for pom fix:

commit 8d2ec0e5bfe5047482e1f11eb38171b119ec5df4
Merge: 547f35d aaddd5a
Author: Bill Burke <bburke>
Date:   Thu Apr 17 17:07:20 2014 -0400

    Merge pull request #493 from kylape/pom-fix

    fixing poms


To include this fix in Branch_2_3(and two more fixes), we need to release a in upstream. Then we can include it in EAP 6.4.

To include this fix in, if we don't want an version update, then we could use the one-off process to patch it in EAP 6.2 only and don't touch anything in upstream.

Comment 5 Kyle Lape 2014-06-02 17:43:30 UTC

The branch this commit is added to in the product git repo is for a one off patch against EAP 6.2.2, which is using 2.3.7 (not  Therefore I believe that fix applied to the correct branch of code.

I admittedly need to have already committed this upstream, which is why I had it applied to the 2_3 branch.  I should have followed through and had it committed to the other branches as well (2_3_7 and 2_3_8).  

If we get it committed to 2_3_7, then we could tag and get that in EAP 6.2.4.  That will be the last release for the 2_3_7 branch.  For EAP 6.3.x, I assume we'll need to create a similar 2_3_8 branch and apply the fix there.  Is that correct?

Comment 6 Weinan Li 2014-06-03 04:58:43 UTC
Hi Kyle,

All correct :-) If we just want one-off patch, then we don't have to merge Branch_2_3_7; If we want for EAP 6.2.4, then we need to merge the fix based from and release

For Branch_2_3, this is currently for 2.3.8, and I saw the fix is already merge. So for EAP 6.4, we will use it to create 2.3.9.

For EAP 6.3.x, we should treat it similar to Branch_2_3_7: If we want one-off patch only for EAP 6.3.x, then we don't need to do anything in upstream; If we want to release, then we need to create a branch called Branch_2_3_8 for EAP 6.3.x.

Comment 7 Weinan Li 2014-06-03 06:33:01 UTC

btw, the current prod-only '2.3.8.Final-redhat' branch is based on this commit:

commit 1dd445e1a193124d0c668fba826614caa657a8d4
Merge: f3f48a4 2bf7a55
Author: Bill Burke <bburke>
Date:   Tue Feb 18 09:58:54 2014 -0500

    Merge pull request #453 from psakar/separete_test_classes

    Separate test classes


Please this branch doesn't exist on upstream RESTEasy, it's in my RESTEasy fork: https://github.com/liweinan/Resteasy/tree/2.3.8.Final-redhat

The problem is caused by some historical reasons. Bill didn't want to go on developing Branch_2_3 so he didn't want to release 2.3.8 that time, so we've decided only to have 2.3.8 internally.

But as PRs go on merging into Branch_2_3, we can't use Branch_2_3 for 2.3.8 only fixes anymore. So we currently have three options for any fixes to 2.3.8 specifically:

1. Any 2.3.8 work should goes into branch 2.3.8.Final-redhat of my fork.
2. We only provide one-off patch to EAP that using 2.3.8.Final, so we don't have any work in upstream or my fork on github.
3. Create a Branch_2_3_8 in upstream as a snapshot of my fork and work in that branch.

Please let me know which option you prefer.

Comment 8 Weinan Li 2014-06-05 09:15:22 UTC
Hi Kyle,

I have discussed this issue with Fernando, and he asked me to wait for EAP 6.4 cycle to release a new version based on Branch_2_3. Here I have some questions:

1. Let's tag an 2.3.9 in upstream for 6.4, is that okay? Could you please help on this? I remember Bill has granted the permission to you.
2. Do we need and for released EAP6.x? If so, could you please help to tag upstream? And I'll create a Branch_2_3_8 in my fork for

Comment 9 Kyle Lape 2014-06-07 01:02:30 UTC tag. is created in github.

Comment 11 Katerina Odabasi 2014-06-19 12:31:34 UTC
Verified in 6.2.4.CP.CR1 with org.jboss.resteasy.plugins.providers.DataSourceProviderTest.

Comment 12 JBoss JIRA Server 2016-08-02 16:15:27 UTC
Alessio Soldano <asoldano> updated the status of jira RESTEASY-779 to Closed

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