pf.c Pflow TOS zeroed out
Hi, We've been maintaining this small patch since 5.8 and it seems to work as expected but could be wrong. Unpatched Behaviour: * netflow always shows TOS values as 0 Patched behaviour: * netflow now shows a TOS value when either set by the PF rule, or if packet originally had the Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.1037 diff -u -p -r1.1037 pf.c --- pf.c4 Jul 2017 14:10:15 -1.1037 +++ pf.c2 Aug 2017 00:51:34 - @@ -2756,7 +2756,7 @@ pf_build_tcp(const struct pf_rule *r, sa h->ip_len = htons(tlen); h->ip_v = 4; h->ip_hl = sizeof(*h) >> 2; -h->ip_tos = IPTOS_LOWDELAY; +h->ip_tos = r->tos; h->ip_len = htons(len); h->ip_off = htons(ip_mtudisc ? IP_DF : 0); h->ip_ttl = ttl ? ttl : ip_defttl; Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.1037 diff -u -p -r1.1037 pf.c --- pf.c4 Jul 2017 14:10:15 - 1.1037 +++ pf.c2 Aug 2017 00:51:34 - @@ -2756,7 +2756,7 @@ pf_build_tcp(const struct pf_rule *r, sa h->ip_len = htons(tlen); h->ip_v = 4; h->ip_hl = sizeof(*h) >> 2; - h->ip_tos = IPTOS_LOWDELAY; + h->ip_tos = r->tos; h->ip_len = htons(len); h->ip_off = htons(ip_mtudisc ? IP_DF : 0); h->ip_ttl = ttl ? ttl : ip_defttl;
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Fri, 7 Aug 2015 22:49:50 +0200 shun.obsd.t...@dropcut.net wrote: Hi Maxime, Hi Sam, I have been following this thread (and others) for some time. On Fri, Aug 07, 2015 at 09:55:21PM +0200, Maxime Villard wrote: Well, I guess I'll have to admit that I find your attitude extremely disrespectful. I have to agree that the emails are rather short and tend to lack the subtle cues of human face-to-face interaction. They can easily get out of hand. I'd like to agree with the sentiment here and in the rest of the mail. The lack of body language and tone can result in misunderstandings. I wasn't trying to be disrespectful. It's very easy to pile on a person's comment on the internet. It feels wasteful to develop a seemingly comprehensive and modular code scanner which will inherently find heaps of bugs, and then not release it or allow others to work with it. I am of course grateful that Maxime and others report bugs, but it feels unusual to me that it's acceptable for somebody to consistently be able to find them with a tool, and yet nobody thinks it'd be a good idea to have that tool shared if Maxime is willing. As many here have acknowledged, Maxime's reports are a contribution. So why not seek to have those contributions continue? _That_ was my point, though it was poorly conveyed, falsely appearing to be sarcasm. Le 21/07/2015 12:31, sam a écrit : On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard m...@m00nbsd.net wrote: Found by The Brainy Code Scanner. It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. How about you release the Brainy Code Scanner then? Maxime, I have to agree with Sam here. I did check your website, but have not found any code there. It would be of great help if you would release it. I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good! Or perhaps you should report 'just' the relatively important ones? I think my work does (or used to) benefit to a lot of users, developers and vendors here; a lot of people, including you. Sam, I think Maxime has done good work so far. There is no reason to mock the work or the person. I thought the motto is Shut Up and Hack! and not Ridicule and Hack!. Nobody supports my work, and I've never asked for anything here about that. Even though I almost never receive a simple thank you for all the bugs and vulnerabilities I've so far reported, I still expect a spiritual thank you for my work. Yes, this is a common problem. Hence: Thank you Maxime! Thank you for all the bugs you (and Brainy) have found so far. Developing, improving and maintaining Brainy takes time and energy, as well as investigating and packaging the bugs and vulnerabilities it finds. You could share that burden. I am willing to give it a shot. shun regards, sam
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
I'm sorry, I misread you. I wasn't trying to make fun of you or disregard your work. Thanks for reporting this (among other bugs). I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. On Fri, 7 Aug 2015 21:55:21 +0200 Maxime Villard m...@m00nbsd.net wrote: Well, I guess I'll have to admit that I find your attitude extremely disrespectful. But I don't tend to feel particularly offended by this kind of things, so it probably does not matter. Le 21/07/2015 12:31, sam a écrit : On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard m...@m00nbsd.net wrote: Found by The Brainy Code Scanner. It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. How about you release the Brainy Code Scanner then? I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good! Or perhaps you should report 'just' the relatively important ones? I think my work does (or used to) benefit to a lot of users, developers and vendors here; a lot of people, including you. Nobody supports my work, and I've never asked for anything here about that. Even though I almost never receive a simple thank you for all the bugs and vulnerabilities I've so far reported, I still expect a spiritual thank you for my work. But I certainly do not expect that kind of emails you just sent, somehow trying to either make fun of me or disregard what I'm willing to spend my spare time on for you. Developing, improving and maintaining Brainy takes time and energy, as well as investigating and packaging the bugs and vulnerabilities it finds. I've so far sent some reports here just because I'm friendly enough, and because modifying a few things for Brainy to properly understand the OpenBSD code does not require a Herculean work. Now, I believe that this effort is too much for my spare time. If you want to say thanks to me for reporting this vulnerability, dear Sam, it's never too late. Maxime
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard m...@m00nbsd.net wrote: Found by The Brainy Code Scanner. It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. How about you release the Brainy Code Scanner then? I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good! Or perhaps you should report 'just' the relatively important ones? Maxime
Re: Brainy: Kernel Use-after-free Memory Leak in hifn
On Mon, 11 May 2015 22:11:10 +0200
Maxime Villard m...@m00nbsd.net wrote:
Hi,
I put here two bugs among others:
sys/dev/pci/hifn7751.c
2757
if (!(m0-m_flags M_EXT))
m_freem(m0);
len = MCLBYTES;
totlen -= len;
m0-m_pkthdr.len = m0-m_len = len;
mlast = m0;
Use-after-free with 'm0'.
sys/dev/pci/hifn7751.c
2766
MGET(m, M_DONTWAIT, MT_DATA);
if (m == NULL) {
m_freem(m0);
return (NULL);
}
MCLGET(m, M_DONTWAIT);
if (!(m-m_flags M_EXT)) {
m_freem(m0);
return (NULL);
}
len = MCLBYTES;
'm' is leaked.
Found by The Brainy Code Scanner.
Maxime
If there are any other unresolved bugs your code scanner has found,
please do report them. It's better for everyone.
Is there any chance you would one day open source it, or tell us what
it is based on? :)
Thanks anyway!
Typo in Tetris
Absolutely trivial, but none the less ... --- tetris-orig/shapes.c2014-08-03 14:12:09.0 +0100 +++ tetris/shapes.c 2014-08-03 14:12:26.0 +0100 @@ -76,7 +76,7 @@ }; /* - * Return true iff the given shape fits in the given position, + * Return true if the given shape fits in the given position, * taking the current board into account. */ int
Re: Typo in Tetris
Well, I've learned something today. Apologies for the noise. On Mon, Aug 4, 2014 at 9:51 AM, Stuart Henderson s...@spacehopper.org wrote: http://en.m.wikipedia.org/wiki/If_and_only_if
Re: shared libs and ports, maybe a proposal
On Thu, 8 Jul 2010, Marc Espie wrote: On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote: On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote: each time xenocara farts, we get new libs (or less libs). in order for updates to work, we *should* propagate those changes to @wantlib in each port. For the base and xenocara libs, wouldn't it make sense to have some modules centralizing the version info (and even some dependencicies) so that instead of WANTLIB declaratons you coud have .include libX11.dep.mk .include libc.dep.mk or something similar? Then only one central fil would need to be updated when revisions changes. And even if libX11 gains new depencies, you would not be reqired to add the manually to a zillon of ports's Makefiles. Nope, because it does not do half the work: bumping pkgnames. Doing stuff automatically every time will mean you will get to update a lot of packages. Basically, if you have two packages with the same name, and differing WANTLIB, how do you know which one is the newest ? the one with the highest CVS revision ID attached? The CVS revision number is guaranteed atomically increasing and only relevant if it's used as a tie breaker against two otherwise similar versions. there's probably an obvious reason why this is a bad idea. Sam -- Talk does not cook rice - Chinese Proverb
