Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

2016-03-24 1:38 GMT+08:00, Pablo Neira Ayuso : > On Thu, Mar 24, 2016 at 12:42:43AM +0800, Baozeng wrote: >> 2016-03-22 23:27 GMT+08:00 Eric Dumazet : >> > Untested patch would be : >> > >> > diff --git a/net/bridge/netfilter/ebtables.c >> >

CISCO IP PHONES AND CPU's

Hi, Our Stock list. Brand NEW 96 x Cisco 7900 IP Phone 87 x Unified IP Phone 6900 12 x Unified IP Phone 8900 76 x Unified IP Phone 9900 55 x Unified IP Phone 8800 67 x Cisco 1921 67 x Cisco 1941 56 x Cisco CP-7961G 7961G 34 x Cisco CP-7971G-GE 7971G 19 x Cisco Unified IP Conference Station 7937G

Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

On Thu, Mar 24, 2016 at 12:42:43AM +0800, Baozeng wrote: > 2016-03-22 23:27 GMT+08:00 Eric Dumazet : > > Untested patch would be : > > > > diff --git a/net/bridge/netfilter/ebtables.c > > b/net/bridge/netfilter/ebtables.c > > index 67b2e27999aa..fceb7354d169 100644 > > ---

Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

On Thu, 2016-03-24 at 00:42 +0800, Baozeng wrote: > Thanks for your quick patch. I tested it but it still reproduce the > bug. We should limit the length of the name, > not the prefix. The following patch fixs it. > > diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c

Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

2016-03-22 23:27 GMT+08:00 Eric Dumazet : > > On Tue, 2016-03-22 at 08:21 -0700, Eric Dumazet wrote: > > On Tue, 2016-03-22 at 23:08 +0800, Baozeng Ding wrote: > > > Hi all, > > > > > > The following program triggers an out-of-bounds bug in > > > sctp_getsockopt. The kernel

Re: [PATCH nft] src: store parser location for handle and position IDs

On 23 March 2016 at 16:51, Pablo Neira Ayuso wrote: > Store the parser location structure for handle and position IDs so we > can use this information from the evaluation step, to provide better > error reporting. > > Signed-off-by: Pablo Neira Ayuso >

[PATCH nft] src: store parser location for handle and position IDs

Store the parser location structure for handle and position IDs so we can use this information from the evaluation step, to provide better error reporting. Signed-off-by: Pablo Neira Ayuso --- include/rule.h| 26 -- src/netlink.c

[PATCH] netfilter: ipv4: fix NULL dereference

From: Liping Zhang Commit fa50d974d104 ("ipv4: Namespaceify ip_default_ttl sysctl knob") introduce the namespaceify ip_default_ttl, but sk_buff->sk maybe NULL, so sock_net(skb->sk) will dereference the NULL pointer and oops will happen. Signed-off-by: Liping Zhang

[nft PATCH 3/3] tests/shell: add testcases for Netfilter bug #965

Testscases for Netfilter bug #965: * add rule at position * insert rule at position * replace rule with given handle * delete rule with given handle * don't allow to delete rules with position keyword Netfilter Bugzilla: http://bugzilla.netfilter.org/show_bug.cgi?id=965 Signed-off-by: Arturo

[nft PATCH 2/3] src/evaluate.c: improve rule management checks

Improve checks (and error reporting) for basic rule management operations. This includes a fix for netfilter bug #965. Netfilter bug: http://bugzilla.netfilter.org/show_bug.cgi?id=965 Reported-by: Jesper Sander Lindgren Suggested-by: Pablo Neira Ayuso

RE: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

Much of the issues raised become redundant due to a much simpler solution proposed by Pablo. Still two issues left, proc and potential existing bug in sk filter case. On March 21, 2016 2:23 PM, Florian Westphal wrote: > It looks like a bug -- AFAICS if a sk filter is active on the nfnetlink sk

Re: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

On Wed, Mar 23, 2016 at 11:40:14AM +, Yigal Reiss (yreiss) wrote: > On Monday, March 21, 2016 11:36 PM, Pablo Neira Ayuso wrote: > > So isn't the more simple patch that I'm attaching achieving what you need? > > Yes. I applied the patch and it works as expected. Indeed much more > simple. > >

[PATCH] netfilter: nfnetlink_queue: honor NFQA_CFG_F_FAIL_OPEN when netlink unicast fails

When netlink unicast fails to deliver the message to userspace, we should also check if the NFQA_CFG_F_FAIL_OPEN flag is set so we reinject the packet back to the stack. I think the user expects no packet drops when this flag is set due to queueing to userspace errors, no matter if related to the

[PATCH] iptables: extensions: libxt_TEE: Add translation to nft

Add translation for TEE target to nft. However, there is a problem with the output when using ip6tables-translate. I couldn't find a fix for that. Examples: $ iptables-translate -t mangle -A PREROUTING -j TEE --gateway 192.168.0.2 --oif eth0 nft add rule ip mangle PREROUTING counter dup to

RE: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size

On Monday, March 21, 2016 11:36 PM, Pablo Neira Ayuso wrote: > So isn't the more simple patch that I'm attaching achieving what you need? Yes. I applied the patch and it works as expected. Indeed much more simple. I intend to use this patch and would like it to eventually get into the formal