i think the short short answer is: an example of what sender can do is here rfc6675
First, TCP receiver does not process SACK fields. SACK, as ACK, is sent by the receiver, i.e., receiver creates information in SACK, and is processed by the sender.
On the receiver:
The actions of the receiver on duplicate packets do not depend on SACK option. TCP receiver should have its receiver buffer. Out-of-order segments within receiver window land in receiver buffer and await in-order-packets before these packets can be delivered to the application. SACK option merely specifies, that when the receiver creates an ACK, it can report that these packets are in the buffer (if this answers the question, you can stop reading).
Also, TCP receiver cannot distinguish between reordered packets and packet losses. So, the general actions are the same. Out-of-order segments are received. TCP acts as if some segments are missing unless they arrive sooner or later [*].
On the sender:
Actions of the sender on SACK segments are not important to the RFCs in question. The RFCs specify how sender can negotiate receiving SACK information from the receiver, should he want to do something with it. Usually, processing of SACK fields is part of the congestion control algorithm, or more precisely its loss recovery part. The congestion control employed by sender is sender's own decision (provided that it won't break the Internet) and is not negotiated. Thus, processing of SACKs is also sender's own decision. One such option is rfc6675. AFAIK the TCP implementation is not required to follow the spec precisely. Linux is slightly different.
[*] in modern TCP implementations this is not exactly true. Reordered packets can cause 3 dupacks and thus trigger actions of congestion control. The sender can utilize reordering detection (I think this is the rfc: rfc4015) that reverts actions of congestion control algorithm.
