Bug 8815 - PIDL based autogenerated code allows overwriting beyond of allocated array; CVE-2012-1182
PIDL based autogenerated code allows overwriting beyond of allocated array; C...
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
3.6.3
All All
: P1 critical
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-15 17:50 UTC by Lars Müller
Modified: 2012-04-11 16:52 UTC (History)
16 users (show)

See Also:


Attachments
draft patches for v3-4-test (1.65 MB, patch)
2012-03-15 17:58 UTC, Stefan Metzmacher
no flags Details
draft patches for v3-5-test (1.76 MB, patch)
2012-03-15 17:58 UTC, Stefan Metzmacher
no flags Details
draft patches for v3-6-test (16.80 KB, patch)
2012-03-15 17:59 UTC, Stefan Metzmacher
no flags Details
draft patches for master (16.80 KB, patch)
2012-03-15 18:03 UTC, Stefan Metzmacher
no flags Details
draft patches for master with gen_ndr (1.33 MB, application/x-gzip)
2012-03-15 18:04 UTC, Stefan Metzmacher
no flags Details
draft patches for v3-3-test (1.30 MB, patch)
2012-03-16 23:24 UTC, Stefan Metzmacher
no flags Details
draft patches for v3-2-test (1.10 MB, patch)
2012-03-16 23:25 UTC, Stefan Metzmacher
no flags Details
Patch for v3-0-test (3.15 KB, patch)
2012-03-17 00:38 UTC, Stefan Metzmacher
jra: review+
Details
First set of reproducers from ZDI (deleted)
2012-04-02 16:13 UTC, Lars Müller
no flags Details
Second set of reproducers from ZDI (deleted)
2012-04-02 16:14 UTC, Lars Müller
no flags Details
draft of the advisory (2.72 KB, text/plain)
2012-04-02 16:59 UTC, Lars Müller
no flags Details
draft of the advisory (2.75 KB, text/plain)
2012-04-02 18:06 UTC, Karolin Seeger
no flags Details
Patches for master with gen_ndr (1.33 MB, application/x-gzip)
2012-04-05 13:30 UTC, Stefan Metzmacher
no flags Details
Patches for master (and samba-4.0.0aplha18) (16.96 KB, patch)
2012-04-05 13:31 UTC, Stefan Metzmacher
metze: review? (gd)
jra: review+
Details
Patches for v3-6-test (16.96 KB, patch)
2012-04-05 13:32 UTC, Stefan Metzmacher
metze: review? (gd)
jra: review+
Details
Patches for v3-5-test (1.76 MB, patch)
2012-04-05 13:33 UTC, Stefan Metzmacher
metze: review? (gd)
jra: review+
Details
Patches for v3-4-test (1.65 MB, patch)
2012-04-05 13:34 UTC, Stefan Metzmacher
metze: review? (gd)
jra: review+
Details
Patches for v3-3-test (1.30 MB, patch)
2012-04-05 13:36 UTC, Stefan Metzmacher
jra: review+
Details
Patches for v3-2-test (1.10 MB, patch)
2012-04-05 13:37 UTC, Stefan Metzmacher
jra: review+
Details
python based reproducers for 3.0.x samba (draft) (deleted)
2012-04-05 14:16 UTC, Guenther Deschner
no flags Details
Assert array-lengths for NULL pointers to be 0 (3.17 KB, patch)
2012-04-06 05:07 UTC, Andrew Bartlett
no flags Details
gen_ndr for master after my patch (151.75 KB, patch)
2012-04-06 05:07 UTC, Andrew Bartlett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Müller 2012-03-15 17:50:10 UTC
From: Volker Lendecke <Volker.Lendecke@SerNet.DE>                               
To: simo <idra@samba.org>                                                       
Cc: security@samba.org                                                          
Date: Thu, 15 Mar 2012 13:00:47 +0100                                           
Subject: Re: PGP Key                                                            

On Thu, Mar 15, 2012 at 07:50:56AM -0400, simo wrote:
>                                                                               
> Volker can you forward them to me so I can activate secalert @ RH and         
> get review and classification asap.                                           

They are encrypted with my key. The 5 alerts are all the
same problem. PIDL autogenerated code when pulling an array
that has a size_is() attribute allocates the array according
to the array length that is implicitly added by the
marshalling code. The loop pulling the array elements
however uses the variable indicated by the size_is()
attribute. Both are distinctly sent by the client, so the
client can force overwriting memory beyond an allocated
array. A quick fix is attached. It is still slightly wrong,
metze is working on a proper fix. But for our use cases it
should be sufficient. To see the problem, you should compare
the ndr_xx.c files before and after the pidl patch was
applied.
Comment 1 Stefan Metzmacher 2012-03-15 17:58:07 UTC
Created attachment 7389 [details]
draft patches for v3-4-test
Comment 2 Stefan Metzmacher 2012-03-15 17:58:53 UTC
Created attachment 7390 [details]
draft patches for v3-5-test
Comment 3 Stefan Metzmacher 2012-03-15 17:59:31 UTC
Created attachment 7391 [details]
draft patches for v3-6-test
Comment 4 Stefan Metzmacher 2012-03-15 18:03:33 UTC
Created attachment 7392 [details]
draft patches for master
Comment 5 Stefan Metzmacher 2012-03-15 18:04:25 UTC
Created attachment 7393 [details]
draft patches for master with gen_ndr
Comment 6 Jeremy Allison 2012-03-16 19:51:27 UTC
Ouch. Been looking into back-porting this into 3.0.x (there are pidl generated files inside source/librpc/gen_ndr/) but there are no idl files or pidl source code in that tree.

Hmmmm. Does anyone remember how these files were generated for 3.0.x and from which IDL source ?

Jeremy.
Comment 7 Stefan Metzmacher 2012-03-16 23:14:32 UTC
(In reply to comment #6)
> Ouch. Been looking into back-porting this into 3.0.x (there are pidl generated
> files inside source/librpc/gen_ndr/) but there are no idl files or pidl source
> code in that tree.
> 
> Hmmmm. Does anyone remember how these files were generated for 3.0.x and from
> which IDL source ?
> 
> Jeremy.

Maybe just copied from the samba4 branch.

I'll upload patch for v3-3-test and v3-2-test soon...
Comment 8 Stefan Metzmacher 2012-03-16 23:24:48 UTC
Created attachment 7398 [details]
draft patches for v3-3-test
Comment 9 Stefan Metzmacher 2012-03-16 23:25:45 UTC
Created attachment 7399 [details]
draft patches for v3-2-test
Comment 10 Stefan Metzmacher 2012-03-17 00:38:16 UTC
Created attachment 7400 [details]
Patch for v3-0-test
Comment 11 Guenther Deschner 2012-03-19 12:28:09 UTC
Before we forget: we need to check the handmarshalling routines (librpc/ndr/ndr_X.c) also. These are typically created from autogenerated code and then modified afterwards, so there is a good chance we need to fix them as well.
Comment 12 Jeremy Allison 2012-03-19 19:32:11 UTC
Ok, I took a quick look inside librpc/ndr/ndr_X.c in master, and the only thing I saw using ndr_check_array() was in ndr_spoolss_buf.c.

Can someone else confirm that's all we have to worry about ?

Jeremy.
Comment 13 Jeremy Allison 2012-03-21 17:41:29 UTC
Ok, I think we have a problem in librpc/ndr/ndr_spoolss_buf.c where we allocate r->file_info based on ndr_get_array_size(ndr, &r->file_info) and then call ndr_check_array_size(ndr, (void*)&r->file_info, r->file_count));

Can someone else confirm this please ?

Jeremy.
Comment 14 Jeremy Allison 2012-03-22 16:47:53 UTC
From metze:

This from master looks correct:

#if 0
                        NDR_CHECK(ndr_pull_array_size(ndr, &r->file_info));
#else
                        NDR_CHECK(ndr_token_store(ndr,
&ndr->array_size_list, &r->file_info, r->file_count));
#endif
                        NDR_PULL_ALLOC_N(ndr, r->file_info,
ndr_get_array_size(ndr, &r->file_info));
                        _mem_save_file_info_1 = NDR_PULL_GET_MEM_CTX(ndr);
                        NDR_PULL_SET_MEM_CTX(ndr, r->file_info, 0);
                        for (cntr_file_info_1 = 0; cntr_file_info_1 <
r->file_count; cntr_file_info_1++) {

NDR_CHECK(ndr_pull_spoolss_DriverFileInfo(ndr, NDR_SCALARS,
&r->file_info[cntr_file_info_1]));
                        }

Because
NDR_CHECK(ndr_token_store(ndr, &ndr->array_size_list, &r->file_info,
r->file_count));
sets the value of ndr_get_array_size() to r->file_count.

metze
Comment 15 Guenther Deschner 2012-03-27 15:37:48 UTC
Ok, seems like the patchset is the final set of changes.

Off-list several people pointed out that we need to have more review of the changes though. Preferably RH or SuSE security teams should take a closer look at the changes and give their OK.

This means we most probably cannot hold the CRD of March, 29th.

Shall we move the CRD by one week to lets say April, 5th ?
Comment 16 Jeremy Allison 2012-03-27 16:34:42 UTC
I agree with the one week move. It will allow testing of the new reports also to ensure the patchset fixes everything.

Jeremy.
Comment 17 Karolin Seeger 2012-03-27 18:03:05 UTC
What about April, 3rd or 10th to avoid shipping (and making the issue public) the evening before the Easter weekend?

Karolin
Comment 18 Lars Müller 2012-03-27 19:47:52 UTC
Better the 10th as it gives a bit more time for testing.
Comment 19 Jeremy Allison 2012-03-28 16:11:20 UTC
Ok, let's make it the 10th !
Jeremy.
Comment 20 Lars Müller 2012-04-02 16:13:41 UTC
Created attachment 7418 [details]
First set of reproducers from ZDI
Comment 21 Lars Müller 2012-04-02 16:14:35 UTC
Created attachment 7419 [details]
Second set of reproducers from ZDI
Comment 22 Lars Müller 2012-04-02 16:25:50 UTC
The security researchers/ team members we like to ask if you're able to see further issues based on the two reproducers added?

If that's the case please speak up now or forever hold your peace.
Comment 23 Lars Müller 2012-04-02 16:59:30 UTC
Created attachment 7420 [details]
draft of the advisory
Comment 24 Lars Müller 2012-04-02 17:05:18 UTC
Comment on attachment 7420 [details]
draft of the advisory

The attached draft was written by Jeremy Allison.  Acknowledged by several Samba team members.
Comment 25 Karolin Seeger 2012-04-02 17:56:14 UTC
Is anyone willing to set the review flags?

Thanks!

Karolin
Comment 26 Karolin Seeger 2012-04-02 18:04:38 UTC
Comment on attachment 7420 [details]
draft of the advisory

this is not the latest version of the advisory
Comment 27 Karolin Seeger 2012-04-02 18:06:35 UTC
Created attachment 7421 [details]
draft of the advisory
Comment 28 Stefan Metzmacher 2012-04-03 12:11:08 UTC
I'll try to upload real patches this evening and ask for review flags then.
Comment 29 Stefan Metzmacher 2012-04-03 20:23:01 UTC
maybe tomorrow...
Comment 30 Andrew Bartlett 2012-04-05 10:19:01 UTC
I'm concerned that this patch isn't correct (sorry).

I've looked at this chunk:

@@ -387,16 +411,18 @@ _PUBLIC_ enum ndr_err_code ndr_push_wbint_Principals(struct ndr_push *ndr, int n
 
 _PUBLIC_ enum ndr_err_code ndr_pull_wbint_Principals(struct ndr_pull *ndr, int ndr_flags, struct wbint_Principals *r)
 {
+	uint32_t size_principals_0 = 0;
 	uint32_t cntr_principals_0;
 	TALLOC_CTX *_mem_save_principals_0;
 	if (ndr_flags & NDR_SCALARS) {
 		NDR_CHECK(ndr_pull_array_size(ndr, &r->principals));
 		NDR_CHECK(ndr_pull_align(ndr, 5));
 		NDR_CHECK(ndr_pull_int32(ndr, NDR_SCALARS, &r->num_principals));
-		NDR_PULL_ALLOC_N(ndr, r->principals, ndr_get_array_size(ndr, &r->principals));
+		size_principals_0 = ndr_get_array_size(ndr, &r->principals);
+		NDR_PULL_ALLOC_N(ndr, r->principals, size_principals_0);
 		_mem_save_principals_0 = NDR_PULL_GET_MEM_CTX(ndr);
 		NDR_PULL_SET_MEM_CTX(ndr, r->principals, 0);
-		for (cntr_principals_0 = 0; cntr_principals_0 < r->num_principals; cntr_principals_0++) {
+		for (cntr_principals_0 = 0; cntr_principals_0 < size_principals_0; cntr_principals_0++) {
 			NDR_CHECK(ndr_pull_wbint_Principal(ndr, NDR_SCALARS, &r->principals[cntr_principals_0]));
 		}
 		NDR_PULL_SET_MEM_CTX(ndr, _mem_save_principals_0, 0);
@@ -406,9 +432,10 @@ _PUBLIC_ enum ndr_err_code ndr_pull_wbint_Principals(struct ndr_pull *ndr, int n
 		NDR_CHECK(ndr_pull_trailer_align(ndr, 5));
 	}
 	if (ndr_flags & NDR_BUFFERS) {
+		size_principals_0 = ndr_get_array_size(ndr, &r->principals);
 		_mem_save_principals_0 = NDR_PULL_GET_MEM_CTX(ndr);
 		NDR_PULL_SET_MEM_CTX(ndr, r->principals, 0);
-		for (cntr_principals_0 = 0; cntr_principals_0 < r->num_principals; cntr_principals_0++) {
+		for (cntr_principals_0 = 0; cntr_principals_0 < size_principals_0; cntr_principals_0++) {
 			NDR_CHECK(ndr_pull_wbint_Principal(ndr, NDR_BUFFERS, &r->principals[cntr_principals_0]));
 		}
 		NDR_PULL_SET_MEM_CTX(ndr, _mem_save_principals_0, 0);

For the memory overwrite in the PIDL code, the generated output is correct.  But there is still no tie (that I can see) between r->num_principals and the size of the array.  This means that we simply move the illigal memory access up the stack, to the application layer which is relying on r->num_principals matching up to the array size.

It seems to me that we must strictly tie the NDR size with application layer variable somehow, presumably via the size_is() expression.  (But that expression can be very complex...)

Am I missing something?
Comment 31 Volker Lendecke 2012-04-05 10:33:21 UTC
(In reply to comment #30)
> I'm concerned that this patch isn't correct (sorry).
> 
> I've looked at this chunk:
> 
> @@ -387,16 +411,18 @@ _PUBLIC_ enum ndr_err_code
> ndr_push_wbint_Principals(struct ndr_push *ndr, int n
> 
>  _PUBLIC_ enum ndr_err_code ndr_pull_wbint_Principals(struct ndr_pull *ndr, int
> ndr_flags, struct wbint_Principals *r)
>  {
> +    uint32_t size_principals_0 = 0;
>      uint32_t cntr_principals_0;
>      TALLOC_CTX *_mem_save_principals_0;
>      if (ndr_flags & NDR_SCALARS) {
>          NDR_CHECK(ndr_pull_array_size(ndr, &r->principals));
>          NDR_CHECK(ndr_pull_align(ndr, 5));
>          NDR_CHECK(ndr_pull_int32(ndr, NDR_SCALARS, &r->num_principals));
> -        NDR_PULL_ALLOC_N(ndr, r->principals, ndr_get_array_size(ndr,
> &r->principals));
> +        size_principals_0 = ndr_get_array_size(ndr, &r->principals);
> +        NDR_PULL_ALLOC_N(ndr, r->principals, size_principals_0);
>          _mem_save_principals_0 = NDR_PULL_GET_MEM_CTX(ndr);
>          NDR_PULL_SET_MEM_CTX(ndr, r->principals, 0);
> -        for (cntr_principals_0 = 0; cntr_principals_0 < r->num_principals;
> cntr_principals_0++) {
> +        for (cntr_principals_0 = 0; cntr_principals_0 < size_principals_0;
> cntr_principals_0++) {
>              NDR_CHECK(ndr_pull_wbint_Principal(ndr, NDR_SCALARS,
> &r->principals[cntr_principals_0]));
>          }
>          NDR_PULL_SET_MEM_CTX(ndr, _mem_save_principals_0, 0);
> @@ -406,9 +432,10 @@ _PUBLIC_ enum ndr_err_code
> ndr_pull_wbint_Principals(struct ndr_pull *ndr, int n
>          NDR_CHECK(ndr_pull_trailer_align(ndr, 5));
>      }
>      if (ndr_flags & NDR_BUFFERS) {
> +        size_principals_0 = ndr_get_array_size(ndr, &r->principals);
>          _mem_save_principals_0 = NDR_PULL_GET_MEM_CTX(ndr);
>          NDR_PULL_SET_MEM_CTX(ndr, r->principals, 0);
> -        for (cntr_principals_0 = 0; cntr_principals_0 < r->num_principals;
> cntr_principals_0++) {
> +        for (cntr_principals_0 = 0; cntr_principals_0 < size_principals_0;
> cntr_principals_0++) {
>              NDR_CHECK(ndr_pull_wbint_Principal(ndr, NDR_BUFFERS,
> &r->principals[cntr_principals_0]));
>          }
>          NDR_PULL_SET_MEM_CTX(ndr, _mem_save_principals_0, 0);
> 
> For the memory overwrite in the PIDL code, the generated output is correct. 
> But there is still no tie (that I can see) between r->num_principals and the
> size of the array.  This means that we simply move the illigal memory access up
> the stack, to the application layer which is relying on r->num_principals
> matching up to the array size.
> 
> It seems to me that we must strictly tie the NDR size with application layer
> variable somehow, presumably via the size_is() expression.  (But that
> expression can be very complex...)
> 
> Am I missing something?

While I haven't really found the exact diff that you are referring to, I think just looking at the patch alone is not sufficient. Further down in the code there used to be calls to ndr_check_array_size that should address exactly your concerns. They should still be there.
Comment 32 Andrew Bartlett 2012-04-05 10:41:42 UTC
Yep, this looks correct once I dived into it more. 

But I'll continue to give a suspicious eye to the output, in case I can find something.  In doing these checks I've become more confident in the patches, which is a good thing. 

Thanks,
Comment 33 Stefan Metzmacher 2012-04-05 13:30:28 UTC
Created attachment 7426 [details]
Patches for master with gen_ndr

Only the commit one commit message was changed.
Comment 34 Stefan Metzmacher 2012-04-05 13:31:24 UTC
Created attachment 7427 [details]
Patches for master (and samba-4.0.0aplha18)

Only the commit one commit message was changed.
Comment 35 Stefan Metzmacher 2012-04-05 13:32:09 UTC
Created attachment 7428 [details]
Patches for v3-6-test

Only the commit one commit message was changed.
Comment 36 Stefan Metzmacher 2012-04-05 13:33:08 UTC
Created attachment 7429 [details]
Patches for v3-5-test

Only the commit one commit message was changed.
Comment 37 Stefan Metzmacher 2012-04-05 13:34:15 UTC
Created attachment 7430 [details]
Patches for v3-4-test

Only the commit one commit message was changed.
Comment 38 Stefan Metzmacher 2012-04-05 13:36:20 UTC
Created attachment 7431 [details]
Patches for v3-3-test

Only the commit one commit message was changed.
Comment 39 Stefan Metzmacher 2012-04-05 13:37:40 UTC
Created attachment 7432 [details]
Patches for v3-2-test

Only the commit one commit message was changed.
Comment 40 Guenther Deschner 2012-04-05 14:16:31 UTC
Created attachment 7433 [details]
python based reproducers for 3.0.x samba (draft)

ZDI did not provide reproducers for the issue in samba 3.0.x (for wkssvc dcerpc), here is a start how such a reproducer might look like.
Comment 41 Andrew Bartlett 2012-04-06 05:07:16 UTC
Created attachment 7436 [details]
Assert array-lengths for NULL pointers to be 0

I'm sorry if I'm still missing something, but I would like someone to look over this particular part for me again.  I agree with Volker that the ndr_check_array_size() call is just outside the diff, but I think we still have an issue here, but in a different element. 

Consider lsa_BinaryString:

	typedef [public] struct {
		uint16 length;
		uint16 size;
		[size_is(size/2),length_is(length/2)] uint16 *array;
	} lsa_BinaryString;

Unlike my previous example, the array here is a pointer.  The critical check for the application layer is:
		if (r->array) {
			NDR_CHECK(ndr_check_array_size(ndr, (void*)&r->array, r->size / 2));
		}

That is, only if the client supplied the pointer, which it may not:

		NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_array));
		if (_ptr_array) {
			NDR_PULL_ALLOC(ndr, r->array);
		} else {
			r->array = NULL;
		}

However, the application layer assumes that if length is non-zero, the array is non-NULL. 

This happens in source3/rpc_server/samr/srv_samr_nt.c:4589 (set_user_info_21)

The attached patch for master asserts that for NULL pointers, that the size_is() and length_is() values are 0, if they are not themselves NULL pointers. 

(gen_ndr to follow, autobuild testing under-way, comments and review required)

Andrew Bartlett


_PUBLIC_ enum ndr_err_code ndr_pull_lsa_BinaryString(struct ndr_pull *ndr, int ndr_flags, struct lsa_BinaryString *r)
{
	uint32_t _ptr_array;
	uint32_t size_array_1 = 0;
	uint32_t length_array_1 = 0;
	uint32_t cntr_array_1;
	TALLOC_CTX *_mem_save_array_0;
	TALLOC_CTX *_mem_save_array_1;
	NDR_PULL_CHECK_FLAGS(ndr, ndr_flags);
	if (ndr_flags & NDR_SCALARS) {
		NDR_CHECK(ndr_pull_align(ndr, 5));
		NDR_CHECK(ndr_pull_uint16(ndr, NDR_SCALARS, &r->length));
		NDR_CHECK(ndr_pull_uint16(ndr, NDR_SCALARS, &r->size));
		NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_array));
		if (_ptr_array) {
			NDR_PULL_ALLOC(ndr, r->array);
		} else {
			r->array = NULL;
		}
		NDR_CHECK(ndr_pull_trailer_align(ndr, 5));
	}
	if (ndr_flags & NDR_BUFFERS) {
		if (r->array) {
			_mem_save_array_0 = NDR_PULL_GET_MEM_CTX(ndr);
			NDR_PULL_SET_MEM_CTX(ndr, r->array, 0);
			NDR_CHECK(ndr_pull_array_size(ndr, &r->array));
			NDR_CHECK(ndr_pull_array_length(ndr, &r->array));
			size_array_1 = ndr_get_array_size(ndr, &r->array);
			length_array_1 = ndr_get_array_length(ndr, &r->array);
			if (length_array_1 > size_array_1) {
				return ndr_pull_error(ndr, NDR_ERR_ARRAY_SIZE, "Bad array size %u should exceed array length %u", size_array_1, length_array_1);
			}
			NDR_PULL_ALLOC_N(ndr, r->array, size_array_1);
			_mem_save_array_1 = NDR_PULL_GET_MEM_CTX(ndr);
			NDR_PULL_SET_MEM_CTX(ndr, r->array, 0);
			for (cntr_array_1 = 0; cntr_array_1 < length_array_1; cntr_array_1++) {
				NDR_CHECK(ndr_pull_uint16(ndr, NDR_SCALARS, &r->array[cntr_array_1]));
			}
			NDR_PULL_SET_MEM_CTX(ndr, _mem_save_array_1, 0);
			NDR_PULL_SET_MEM_CTX(ndr, _mem_save_array_0, 0);
		}
		if (r->array) {
			NDR_CHECK(ndr_check_array_size(ndr, (void*)&r->array, r->size / 2));
		}
		if (r->array) {
			NDR_CHECK(ndr_check_array_length(ndr, (void*)&r->array, r->length / 2));
		}
	}
	return NDR_ERR_SUCCESS;
}
Comment 42 Andrew Bartlett 2012-04-06 05:07:57 UTC
Created attachment 7437 [details]
gen_ndr for master after my patch
Comment 43 Andrew Bartlett 2012-04-06 05:24:51 UTC
Sorry for the noise.  

While I still think the issue I found is genuine, it is distinct, and patching the IDL layer is difficult as winreg (at least) expects this behaviour.  We may have to find and fix all the callers.

I'll try and find someone on the team to explore this in more detail with over Easter, and perhaps file a new bug.
Comment 44 Karolin Seeger 2012-04-09 17:38:45 UTC
Still waiting for the review flags. I will go ahead anyway if there are no objections.
Comment 45 Volker Lendecke 2012-04-09 18:27:56 UTC
While the formal review flag has been missing, please go ahead. All comments say this has been positively tested.
Comment 46 Jeremy Allison 2012-04-09 18:40:12 UTC
Ok, I'll put my neck on the line and positively review :-). I have tested these patches (and caused them to be tested at several OEM's) and they've passed.

Jeremy.
Comment 47 Karolin Seeger 2012-04-09 18:56:09 UTC
(In reply to comment #46)
> Ok, I'll put my neck on the line and positively review :-). I have tested these
> patches (and caused them to be tested at several OEM's) and they've passed.
> 
> Jeremy.

Thanks, Jeremy! :-)
Comment 48 Huzaifa Sidhpurwala 2012-04-10 14:38:01 UTC
What time does this go public today?
Comment 49 Karolin Seeger 2012-04-10 14:41:26 UTC
(In reply to comment #48)
> What time does this go public today?

~1h
Comment 50 Karolin Seeger 2012-04-10 15:42:46 UTC
(In reply to comment #34)
> Created attachment 7427 [details]
> Patches for master
> 
> Only the commit one commit message was changed.

Pushed to autobuild.
Comment 51 Karolin Seeger 2012-04-10 15:43:34 UTC
(In reply to comment #33)
> Created attachment 7426 [details]
> Patches for master with gen_ndr
> 
> Only the commit one commit message was changed.

Metze, are these patches needed in addition to the "Patches for master"?
Comment 52 Karolin Seeger 2012-04-10 15:45:20 UTC
Patches for v3-6, v3-5 and v3-4 have been pushed to the release branches and Samba 3.6.4, 3.5.14 and 3.4.16 have been issued as security releases.
Closing out bug report.

Thanks!
Comment 53 Stefan Metzmacher 2012-04-10 20:15:14 UTC
(In reply to comment #51)
> (In reply to comment #33)
> > Created attachment 7426 [details] [details]
> > Patches for master with gen_ndr
> > 
> > Only the commit one commit message was changed.
> 
> Metze, are these patches needed in addition to the "Patches for master"?

No, they're just for review the resulting changes
Comment 54 Stefan Metzmacher 2012-04-11 12:59:41 UTC
Comment on attachment 7427 [details]
Patches for master (and samba-4.0.0aplha18)

This also applies to samba-4.0.0alpha18
Comment 55 Lars Müller 2012-04-11 14:17:04 UTC
The content of attachment 7433 [details] has been deleted by
    Lars Müller <lars@samba.org>
who provided the following reason:

Remove 3.0 reproducer.

The token used to delete this attachment was generated at 2012-04-11 14:15:55 UTC.
Comment 56 Lars Müller 2012-04-11 16:51:42 UTC
The content of attachment 7418 [details] has been deleted by
    Lars Müller <lars@samba.org>
who provided the following reason:

Remove reproducer.

The token used to delete this attachment was generated at 2012-04-11 16:51:17 UTC.
Comment 57 Lars Müller 2012-04-11 16:52:06 UTC
The content of attachment 7419 [details] has been deleted by
    Lars Müller <lars@samba.org>
who provided the following reason:

Remove reproducer.

The token used to delete this attachment was generated at 2012-04-11 16:52:00 UTC.