Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend is postgresql version 8.1.3.
Today I got errors in logfiles, saying: messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]: ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in: http://lists.iptel.org/pipermail/serusers/2005-May/019681.html with much more detailed description of error, database contents and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error: in mysql/val.c function str2val states: if (!_s) { memset(_v, 0, sizeof(db_val_t)); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } VAL_NULL(_v) = 0; and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the: if (!_s) { DLOG("str2valp", "got a null value"); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } without explicit notification that this is not-NULL value. More than, nowhere else in this function VAL_NULL(_v) not set to 0. So, if a value _v.val contained anyting but 0 at the function start, resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and everyting will be ok. At least for me it's ok for some hours :)
This bug has been fixed in stable branch (rev.1.4.2.2 quite some time ago), but thank you for submission. I will add patch into FreeBSD port.
-Maxim
Alexandre Snarskii wrote:
Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend is postgresql version 8.1.3.
Today I got errors in logfiles, saying: messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]: ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in: http://lists.iptel.org/pipermail/serusers/2005-May/019681.html with much more detailed description of error, database contents and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error: in mysql/val.c function str2val states: if (!_s) { memset(_v, 0, sizeof(db_val_t)); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } VAL_NULL(_v) = 0; and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the: if (!_s) { DLOG("str2valp", "got a null value"); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } without explicit notification that this is not-NULL value. More than, nowhere else in this function VAL_NULL(_v) not set to 0. So, if a value _v.val contained anyting but 0 at the function start, resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and everyting will be ok. At least for me it's ok for some hours :)
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Mon, May 29, 2006 at 10:48:52AM -0700, Maxim Sobolev wrote:
This bug has been fixed in stable branch (rev.1.4.2.2 quite some time ago), but thank you for submission. I will add patch into FreeBSD port.
May I humbly ask you to add other diffs between ser-0.9.7 and 0.9.6 modules/postgres as FreeBSD patch too ?
There is at least one remote-triggered stack overflow there that fixed only in 0.9.7, not exploitable for remote shell, I suppose, but still source of possible DoS on ser-0.9.6/PostgreSQL installatioins...
PS: if you or other developers interested in details - please, contact me off-list.
-Maxim
Alexandre Snarskii wrote:
Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend is postgresql version 8.1.3.
Today I got errors in logfiles, saying: messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]: ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in: http://lists.iptel.org/pipermail/serusers/2005-May/019681.html with much more detailed description of error, database contents and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error: in mysql/val.c function str2val states: if (!_s) { memset(_v, 0, sizeof(db_val_t)); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } VAL_NULL(_v) = 0; and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the: if (!_s) { DLOG("str2valp", "got a null value"); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } without explicit notification that this is not-NULL value. More than, nowhere else in this function VAL_NULL(_v) not set to 0. So, if a value _v.val contained anyting but 0 at the function start, resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and everyting will be ok. At least for me it's ok for some hours :)
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Snar, can you please send me a patch in question? I will be happy to add it to the port. Thanks!
-Maxim
Alexandre Snarskii wrote:
On Mon, May 29, 2006 at 10:48:52AM -0700, Maxim Sobolev wrote:
This bug has been fixed in stable branch (rev.1.4.2.2 quite some time ago), but thank you for submission. I will add patch into FreeBSD port.
May I humbly ask you to add other diffs between ser-0.9.7 and 0.9.6 modules/postgres as FreeBSD patch too ?
There is at least one remote-triggered stack overflow there that fixed only in 0.9.7, not exploitable for remote shell, I suppose, but still source of possible DoS on ser-0.9.6/PostgreSQL installatioins...
PS: if you or other developers interested in details - please, contact me off-list.
-Maxim
Alexandre Snarskii wrote:
Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend is postgresql version 8.1.3.
Today I got errors in logfiles, saying: messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]: ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in: http://lists.iptel.org/pipermail/serusers/2005-May/019681.html with much more detailed description of error, database contents and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error: in mysql/val.c function str2val states: if (!_s) { memset(_v, 0, sizeof(db_val_t)); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } VAL_NULL(_v) = 0; and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the: if (!_s) { DLOG("str2valp", "got a null value"); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } without explicit notification that this is not-NULL value. More than, nowhere else in this function VAL_NULL(_v) not set to 0. So, if a value _v.val contained anyting but 0 at the function start, resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and everyting will be ok. At least for me it's ok for some hours :)
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Alexandre Snarskii -
Maxim Sobolev